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1.0 


SCOPE 


1.1  "\  v  Identifi cation 

^This  specification  establishes  the  requirements  for  performance, 
design,  test,  and  qualification  of  a  computer  program  identified  as 
Operational  Flight  Program  (OFP),  Executive  Software  for  the  Integrated 
Digital  Avionics  for  the  Medium  STOL  Transport  (IDAMST)^) 

1.2  Functional  Summary 

*s'^’The  IDAMST  Executive  Software  Systems  provides  the  system  soft¬ 
ware  services  for  the  application  software.  It  has  been  divided  into  three 

major  functions  denoted  as  Master  Executive,  Local  Executive  and  Monitor 
Executive  Functions.  These  functions  provide  services  for  the  execution  of 
real-time  applications,  data  bus  management,  system  control,  common  data 
utilization  and  Remote  Terminals  communication. 

2.0  Applicable  Documents 

The  following  documents  of  the  exact  Issue  shown  form  a  part  of 
this  specification  to  the  extent  specified  herein.  In  the  event  of  conflict 
between  the  documents  referenced  herein  and  the  contents  of  this  specifica¬ 
tion,  the  contents  of  this  specification  shall  be  considered  a  superseding 
requirement. 


Specifications: 

1)  OFP  IDAMST  Error  Handling  and  Recovery  System  Software 
(EHARS),  SD2042 

2)  System  Specification  Type  A  SI  1010,  June  1976 

3)  Control /Display  System  Segment  Spec  Type  A  SR  5020. 

Other  Publications: 

1)  Specifications  for  IDAMST  Software  Technical  Report 

2)  DAIS  Mission  Software  Executive  Specification 
F3361 5-75-C-1181 ,  26  December  1975 
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3.0  REQUIREMENTS 

3.1  Program  Definition 

3.1.1  Hardware  Interfaces 

The  IDAMST  Executive  System  Interfaces  with  the  following  ele¬ 
ments  of  hardware:  a  Bus  Control  Interface  Unit  (BCIU),  Remote  Terminals, 
Mass  Memory,  a  Processor  Control  Panel  (PCP),  and  Processors. 

3. 1.1.1  Bus  Control  Interface  Unit  (BCIU) 

The  Bus  Control  Interface  Unit  (BCIU)  shall  provide  the  Inter¬ 
face  control  and  data  transfer  function  required  to  connect  a  Processor  with 
two  multiplexed  data  buses.  The  BCIU  shall  be  directed  to  operate  In  a  mode 
by  Its  Interfacing  processor.  The  following  are  the  modes  In  which  the  BCIU 
shall  be  capable  of  operating: 

a.  Remote  Mode,  providing  transfer  of  date  In  both  directions 
between  the  Processor  and  either  of  the  two  Buses,  providing  status  replies 
on  the  appropriate  bus  In  response  to  commands,  and  special  Internal  opera¬ 
tions  and  Interrupts  to  the  associated  processor  upon  receipt  of  certain 
special  commands  on  the  data  buses. 

b.  Master  Mode,  providing  control  of  the  data  bus  based  upon 
Instructions  fetched  from  the  memory  of  the  Processor  through  the  Direct 
Memory  Access  (OMA)  Channel  by  the  BCIU. 

This  Master  Control  mode  shall  result  In: 

1.  The  BCIU  Issuing  Bus  Commands  to  other  devices  on  the  Data 

Buses. 


2.  Participating  in  data  transfers  on  the  buses  (when  the 
Instruction  dictates  it). 
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3.  Checking  status  responses  from  devices  on  the  data  buses. 

4.  Checking  formats  of  the  data  bus  operation. 

5.  Reporting  of  error  conditions  to  the  processor. 

At  any  time,  there  shall  only  be  one  BCIU  in  Master  Mode. 

3. 1.1. 1.1  Instruction  Format 

The  BCIU  Instruction  list  Is  composed  of  pairs  of  instructions 
accessed  by  the  BCIU  using  a  DMA  channel.  The  BCIU  sequentially  Interprets 
Instruction  pairs  to  determine  the  action  required.  The  format  of  the  in¬ 
struction  pair  is  shown  in  Figure  1. 

Each  of  the  fields  in  the  two  word  instruction  have  the 
following  uses: 


a.  OP  CODE  -  These  two  bits  deterlne  the  function  of  the 

comnand. 


00  *  Halt  the  BCIU.  This  Is  always  the  last  command  In  a 
list  and  denotes  that  no  other  command  Is  to  be  performed.  When  the  BCIU 
executes  this  instruction  the  Halt  bit  is  set  inthe  Internal  Status  Register 
and  a  BCIU  level  1  Interrupt  will  be  generated. 

01  ■  Link.  This  OP  code  Is  used  to  link  sections  of  the 
command  list.  Thus,  the  individual  Instructions  of  the  command  list  need 
not  occupy  contiguous  memory  locations.  The  second  word  of  the  Instruction 
Is  used  as  the  address  of  the  next  two  word  Instruction.  The  other  fields 
of  the  Instruction  are  Ignored  except  for  the  interrupt  (I)  field. 
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BCIU  INSTRUCTION  FORMAT 


F 


**  f 


MMa-i  -« 


10  =  No  Operation.  This  OP  code  has  two  uses.  The  first 
Is  to  cancel  commands  which  the  Master  Processor  no  longer  wishes  the  Master 
BCIU  to  perform. 


The  second  is  to  create  a  processor  Interrupt  before  the 
next  BCIU  Instruction  is  generated.  A  typical  use  of  the  latter  case  is 
sending  Mode  Commands.  The  Mode  Data  Register  must  be  set  before  the  com¬ 
mand  Is  sent.  Thus,  the  Interrupt  causes  a  BCIU  pause  which  permits  the 
Master  Processor  to  set  the  MDR  and  then  set  the  Continue  Bit  In  the  PCR  to 
reset  BCIU  processing. 

For  this  OP  code  only  the  Interrupt  field  Is  examined. 

All  other  options  are  ignored. 

11  =  Bus  Operation.  For  this  operation  the  rest  of  the  fields 
are  Interpreted  as  reception  or  transmission  across  the  Bus. 

b.  RETRY  -  If  the  transmission  attempted  by  this  instruction 
was  not  successfully  completed,  and  this  field  is  not  zero,  then  the  trans¬ 
mission  will  be  retired  up  to  three  times. 

c.  SPARE  -  This  bit  is  not  used. 

d.  I  -  If  this  bit  is  set,  successful  completion  of  this 
instruction  will  cause  an  interrupt.  The  PCI  bit  in  the  ISR  will  be  set. 

The  interrupt  will  be  of  level  1.  The  discussion  accompanying  the  No  Opera¬ 
tion  Code  explains  the  use  of  this  bit,  although  the  bit  nay  be  used  in  any 
of  the  four  instructions. 

e.  RECEIVE  DEVICE  ADDRESS  -  This  field  contains  the  address  of 
the  terminal  to  receive  the  message.  This  field  Is  only  used  for  BCIU  In¬ 
struction  OP  code  "Bus  Operation"  (11).  If  the  Receive  Device  Address  Is 
not  the  address  of  the  Master  BCIU  (as  contained  In  the  BCIU  address  field 
of  the  PCR),  then  a  Receive  Comnand  will  be  formed  by  concatenating  the 
Receive  Device  Address  Field,  a  bit  denoting  Receive,  the  Receive  Subaddress/ 
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Mode  field,  and  the  Word  Count/Mode  Code  field.  This  receive  command  will 
then  be  transmitted  across  the  Bus. 


If  the  Receive  Device  Address  field  Is  the  address  of  this 
BCIU  and  the  Receive  Subaddress/Mode  field  Is  not  zero  (l.e..  this  Is  not  a 
Mode  Command),  then  the  Receive  Subaddress  field  will  be  used  to  load  the 
Data  Address  Register  {see  Section  3.1.1,1.2.15)  which  will  then  determine 
where  the  received  message  will  be  stored. 

f.  RECEIVE  SUBADDRESS/MODE  -  This  field  describes  the  message 
to  be  received.  The  use  of  this  field  Is  described  In  the  Receive  Device 
Address  field.  If  this  address  were  zero  It  would  Indicate  that  this  Is  a 
Mode  Command. 


g.  WORD  COUNT/MODE  CODE  -  For  mode  commands  this  field  con¬ 
tains  the  number  of  the  command.  For  Receive/Transmit  commands  this  field 
contains  the  number  of  data  words  to  be  transmitted. 

h.  B  -  This  field  Indicates  which  Bus  will  be  used  for  data 
transmission.  If  this  bit  Is  zero.  Bus  number  one  will  be  used.  If  this 
bit  Is  one.  Bus  number  two  will  be  used. 

1.  TRANSMIT  DEVICE  ADDRESS  -  This  field  Is  similar  to  the 
Receive  Device  Address  except  that  it  is  the  address  of  the  terminal  which 
will  send  the  message. 

If  the  address  Is  not  that  of  this  Master  BCIU,  then  Trans¬ 
mit  Conmand  will  be  formed  by  concentrating  the  Transmit  Device  Address 
field,  the  Transmit  bit,  the  Transmit  Subaddress/Mode  field  and  the  Word 
Count/Mode  Code  field. 

If  the  Transmit  Device  Address  field  Is  the  address  of  this 
terminal  then  the  Data  Address  Register  will  be  formed  (see  Section 
3.1.1,1.2.15)  and  the  data  will  be  written  Into  the  Bus  from  that  address. 
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For  Mode  Commands  the  Transmit  Device  Address  field  Is  the 
address  of  the  terminal  to  receive  the  Mode  Command  and  the  Receive  Device 
Address  field  Is  the  address  of  the  Master  BCIU. 

It  Is  an  error  for  the  Receive  Device  Address  field  and  the 
Transmit  Device  Address  field  to  be  the  same  device.  This  error  will  cause 
an  Interrupt  of  level  1  and  the  I VI  bit  will  be  set  In  the  Internal  Status 
Register. 


j.  TRANSMIT  SUBADDRESS/MODE  -  The  use  of  this  field  has  been 
discussed  In  the  description  of  the  Transmit  Device  Address  field. 

For  mode  commands,  both  the  Transmit  Subaddress  and  Receive 
Subaddress  will  be  zero. 

3. 1.1. 1.2  BCIU  Registers 

The  registers  on  the  BCIU  control  Its  mode  of  operation,  pro¬ 
vide  Information  for  the  master  processor  and  provide  Information  to  Its 
local  processor.  There  are  sixteen,  16-bit  registers  accessible  to  the 
processor  through  the  PIO. 

These  registers  and  their  respective  PIO  addresses  are  listed 
In  Table  I.  Their  description  follows: 

3. 1.1. 1.2.1  Processor  Control  Register  (PCR) 

This  register's  format  Is  Illustrated  In  Figure  2. 

The  description  of  this  format  follows: 

a.  Master  -  This  bit  Is  set  to  logic  1  by  the  processor,  to 
direct  the  BCIU  to  operate  In  Master  Mode. 

b.  GO  -  Set  to  logic  1  by  the  processor  to  Indicate  the  BCIU 
Is  to  enter  an  operational  mode.  A  logic  0  Indicates  the  termination  of  an 
operational  mode.  A  HALT  Instruction  In  master  mode  will  set  It  to  logic  0. 
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TABLE  I.  BCIU  REGISTERS 


PIO  ADDRESS 


0 

PROCESSOR  CONTROL  REGISTER  (PCR) 

1 

INTERNAL  STATUS  REGISTER  (ISR) 

2 

BASE  ADDRESS  REGISTER  (BAR) 

3 

INSTRUCTION  ADDRESS  REGISTER  (IAR) 

4 

BUILT-IN-TEST  REGISTER  (BITR) 

5 

MODE  DATA  REGISTER  (MDR) 

6 

LAST  COMMAND  REGISTER  (LCR) 

7 

STATUS  CODE  REGISTER  (SCR) 

8 

MASTER  FUNCTION  REGISTER  (MFR) 

9 

POINTER  REGISTER  (PR) 

10 

DATA  ADDRESS  REGISTER  (DAR) 

11 

WORD  COUNT  REGISTER  (WCR) 

12 

XMIT  STATUS  WORD  REGISTER  (XSWR) 

13 

RECV  STATUS  WORD  REGISTER  (RSWR) 

14 

INSTRUCTION  WORD  REGISTER  1  (IWR1) 

15 

INSTRUCTION  WORD  REGISTER  2  (IWR2) 

14 


c.  FAIL  -  Set  to  logic  1  after  detecting  an  error  In  self-test. 

d.  SPARE  -  Set  to  logic  0. 

e.  System  Reset  Acknowledge  -  Set  to  logic  1  by  the  processor 
to  Indicate  acknowledgement  of  the  power-on-reset  Interrupt. 

f-  Self-Test  By-Pass  -  Set  to  logic  1  by  the  processor  Indicate 
that  the  BCIU  Is  not  to  perform  self- test. 

9*  BCIU  Address  -  These  5  bits  shall  be  set  by  the  processor 
to  Indicate  the  address  on  the  BCIU. 

h.  SPARE  -  Set  to  logic  0. 

1.  READY  -  Set  to  logic  1  by  the  BCIU  after  completing  Its 
power-on  Initialization. 

j.  BUSY/CONT  -  Set  to  logic  1  by  the  remote  processor  to 
Indicate  the  BCIU  Is  to  enter  BUSY  state.  It  Is  set  to  logic  by  the  BCIU 
after  having  been  directed  to  exit  BUSY  state. 

In  master  mode,  the  bit  Is  set  to  logic  by  master  processor 
to  Indicate  to  the  BCIU  that  an  Interrupt  has  been  processed. 

k.  RUN  -  Set  to  logic  1  by  BCIU  after  being  directed  to  enter 
an  operational  mode  or  upon  exciting  a  BUSY  state.  It  Is  set  to  by  the 
BCIU  after  terminating  an  operational  mode. 
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3. 1.1. 1.2. 2  Internal  Status  Register  (ISR) 

This  register  shall  be  set  only  by  the  BCIU.  It  contains  Indi¬ 
cations  of  the  cause  of  a  BCIU  generated  Interrupt.  This  register  Is  clear¬ 
ed  by  the  BCIU  prior  to  processing  a  new  Instruction  or  command. 

t 

This  register's  format  and  the  meaning  of  each  bit  Is  Indicated 
In  Figure  3.  The  interrupt  levels  generated  by  these  bits  are 

also  indicated  in  this  figure. 

A  description  of  each  bit  follows: 

a.  HALT  (H)  This  bit  shall  be  set  to  logic  1,  In  Master  Mode 
only,  to  Indicate  that  the  BCM  has  processed  a  HALT  Instruction.  The  oper¬ 
ational  mode  (Master)  shall  be  terminated. 

b.  Program  Controlled  Interrupt  (PCI)  This  bit  shall  be  set  to 
logic  1,  in  Master  Mode  only,  after  completion  of  2  word  Instruction  opera¬ 
tion  in  which  PCI  was  requested  (PCI«1). 

c.  Invalid  Instruction  ( I VI )  In  Master  Mode  only,  this  bit 
shall  be  set  to  logic  1  If  the  Device  Address  within  the  Receive  field  of 
the  2-word  Instruction  Is  equal  to  the  Device  Address  within  the  Transmit 
field. 


d.  System  Interrupt  (SI)  In  REmote  Mode  only,  this  bit  shall  be 
set  to  logic  1  upon  receiving  the  System  Interrupt  Mode  Command. 

e.  Mode  Data  Present  (MDP)  This  bit  shall  be  set  to  logic  1,  In 
Master  Mode  only,  after  successfully  receiving  the  Data  Word  associated  with 
Mode  Operations  (Interrupt  results  from  mode  operations  3,  10,  11,  and  13  - 
Refer  to  paragraph  3. 2. 1.1.1.). 
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FIGURE  3.  INTERNAL  STATUS  REGISTER  (ISR) 


f.  Asynchronous  Message  Xmlt/Recv  (AXR)  In  Master  or  Remote 
Modes,  this  bit  shall  be  set  In  conjunction  with  Bit  6  (AM)  to  Indicate 
whether  the  BCIU  was  the  Receiver  (AXR«0)  or  the  Transmitter  (AXR-1)  of  an 
asynchronous  message  (Sub-Address«31 ). 

g.  Asynchronous  Message  (AM)  In  Master  or  Remote  Modes,  this 
bit  shall  be  set  to  logic  1  after  successful  completion  of  an  asynchronous 
bus  message  operation  (Sub-Address*31). 

h.  Master  Function  (MF)  This  bit  shall  be  set  to  logic  1,  In 
Remote  Mode  only,  after  receiving  the  Master  Function  Mode  Command. 

1.  Transmit  Status  Exception  (XSEX)  This  bit  shall  be  set  to 
logic  1,  In  Master  Mode  only,  after  receiving  an  excepted,  valid  status  word 
associated  with  a  Remote  device  In  Transmit  Mode  In  which  the  Message  Error, 
Terminal  Failure,  or  Status  Code  Is  non-zero.  The  status  word  shall  be 
placed  Intact  within  the  Xmlt  Status  Word  Register. 

j.  Receive  Status  Exception  (RSEX)  This  bit  shall  be  set  to 
logic  1,  In  Master  Mode  only,  after  receiving  an  expected,  valid  status  word 
associated  with  a  Remote  device  In  Receive  Mode  in  which  the  Message  Error, 
Terminal  Failure,  or  Status  Code  Is  non-zero.  The  status  word  shall  be 
placed  intact  within  the  Received  Status  Word  Register. 


k.  Transmit  Status  Error  (XSE)  This  bit  shall  be  set  to  logic 
1,  In  Master  Mode  only.  If  an  expected  status  word  associated  with  a  Remote 
device  In  Transmit  Mode  is  not  received.  Is  received  Invalldly,  Is  received 
validly  with  bad  parity,  or  Is  received  validly  with  good  parity  with  a 
Device  Address  that  does  not  match  the  Transmit  Device  Address  within  the 
2-word  Instruction. 


l.  Receive  Status  Error  (RSE)  This  bit  shall  be  set  to  logic  1, 
In  Master  Mode  only.  If  an  expected  status  word  associated  with  a  Remote 
Device  In  Receive  mode.  Is  not  received,  Is  received  invalldly,  is  received 
validly  with  bad  parity,  or  Is  received  validly  with  good  parity  with  a 
Device  Address  that  does  not  match  the  Receive  Device  Address  within  the  2- 
word  Instruction. 

m.  No  Data  Receive  (NDR)  This  bit  shall  be  set  to  logic  1,  In 
Master  Mode  only,  after  commanding  a  remote  device  to  transmit  one  or  more 
data  words  and  the  first  such  data  word  has  not  arrived  within  60  micro¬ 
seconds  after  status  word  reception. 

n.  Incomplete  Data  (ICD)  This  bit  shall  be  set  to  logic  1,  In 
Master  Mode  only,  after  receiving  at  least  one  expected  data  word  and  with 
further  data  words  expected,  the  next  data  word  Is  not  received  within  60 
microseconds  after  reception  of  the  last  data  word. 

o.  Invalid  Data  (IVD)  This  bit  shall  be  set  to  logic  1,  in 
Master  Mode  only,  after  an  expected  data  word  was  received  with  Parity  Error 
indicated.  Data  word  reception  continues. 

p.  Direct  Memory  Access  Error  (DMA)  This  bit  shall  be  set  to 
logic  1,  In  Master  or  Remote  Mode,  after  an  unrecoverable  DMA  Error  is  de¬ 
tected  while  attempting  to  fetch  an  Instruction  word,  a  pointer  word,  or  a 
data  word  from  main  memory  or  while  attempting  to  store  a  tag  word  or  a  data 
word  into  main  memory. 
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3. 1.1. 1.2. 3  Base  Address  Register  (BAR) 

This  register  shall  be  set  only  by  a  Processor  for  the  associa¬ 
ted  BCIU  (Master/Remote)  and  shall  contain  the  most  significant  10  bits  of  a 
pointer  word  address  within  main  memory  for  a  given  data  transfer  operation. 
The  addressed  pointer  word  shall  contain  the  true  data  block  address. 

3. 1.1. 1.2. 4  Instruction  Address  Register  (IAR) 

This  register  shall  be  met  only  by  a  Processor  whose  associated 
BCIU  Is  to  operate  In  Master  Mode.  The  register  shall  contain  the  main  mem¬ 
ory  address  of  the  Initial  2-word  Instruction  executed,  the  BCIU  shall  modify 
the  register  In  order  to  reflect  the  address  of  the  next  Instruction  to  be 
executed.  The  register  shall  be  unused  In  Remote  Mode. 

3. 1.1. 1.2. 5  Last  Command  Register  (LCR) 

This  register  shall  be  used  only  In  support  of  the  Transmit 
Last  Conmand  Mode  Command.  In  Remote  mode,  the  BCIU  shall  place  commands 
which  are  received  validly  and  directed  to  the  particular  BCIU  Into  this 
register.  Exceptions  shall  be  Transmit  Status  Word,  Transmit  Bit  Word,  and 
the  Transmit  Last  Command  Itself. 

3. 1.1. 1.2. 6  Built-In  Test  Word  Register  (BITR) 

This  register  shall  be  used  to  either  maintain  the  Built-In  Test 
Word  (Remote  Mode),  or  to  temporarily  hold  Terminal  Failure  or  bus  monitoring 
of  own  transmission  Information  (Master  Mode).  The  format  of  a  BCIU  BIT  word 
Is  shown  In  Figure  4,  and  described  In  the  following  paragraphs. 

a.  Power-On-Reset  This  bit  shall  be  set  to  logic  1  If  the  BCIU 
performs  Power-On  Initialization. 

b.  Power  Supply  Failure  This  bit  shall  be  set  to  Logic  1 


In  the  event  of  failure. 
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c.  BIM  1  Out  This  bit  shall  be  set  to  logic  1  by  the  Remote 
Mode  BCIU  after  powering  down  BIM  1  as  a  result  of  receiving  a  Remove  Power 
BIM  1  Mode  Command.  The  BIT  shall  Indicate  that  power  has  been  removed  from 
BIM  1. 

# 

d.  BIM  2  Out  This  bit  shall  be  set  to  logic  1  by  the  Remote 
mode  BCIU  after  powering  down  BIM  2  as  a  result  of  receiving  a  Remove  Power 
BIM  2  Mode  Command.  The  bit  shall  Indicate  that  power  has  been  removed  from 
BIM  2. 


e.  DMA  Error  This  bit  shall  be  set  to  logic  1  by  the  Remote 
Mode  BCIU  after  an  unrecoverable  direct  memory  access  error  Is  detected  while 
fetching  data  words  from  or  storing  data  words  (excluding  tag  words)  Into 
main  memory. 


f.  Failure  Code  Errors  The  failure  code  shall  be  set  to  Indi¬ 
cate  detected  self- test  failures  as  follows: 


o  No  failure  00000 
o  BIM  #1  failure  10001 
o  BIM  #2  failure  10010 
o  MROM  Parity  Error  10011 
o  BCM  Data  Flow  Error  10100 
o  BCM  DROM  Error  10101 
o  BCM  SEQ  Error  10110 


o  PIM  DMA  Data  Flow  Error  10111 

g.  No  Data  Received  This  bit  shall  be  set  to  logic  1  by  the 
Remote  Mode  BCIU  after  having  been  directed  to  receive  one  or  more  data  words 
and  the  first  such  data  word  has  not  arrived  within  75  microseconds  after 
command  word  reception. 

h.  Word  Count  Low  This  bit  shall  be  set  to  logic  1  by  the  Re¬ 
mote  Mode  BCIU  after  having  been  directed  to  receive  two  or  more  data  words, 
at  least  one  such  data  word  has  arrived,  but  the  next  expected  data  word  does 
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not  arrive  within  60  microseconds  of  last  data  word  reception. 

1.  Word  Count  High  This  bit  shall  be  set  to  a  logic  1  by  the 
Remote  Mode  BCIU  after  detecting  another  Data  Word  after  the  word  count  Is 
zero. 

/ 

j.  Data  Parity  Error  This  bit  shall  be  set  to  logic  1  by  the 
Remote  BCIU  after  an  expected  data  word  was  received  with  Parity  Error  Indi¬ 
cated.  Data  word  reception  continues. 

k.  Invalid  Data  This  bit  shall  be  set  to  logic  1  by  the  Remote 
mode  BCIU  after  an  expected  data  word  was  received  with  RECV  WORD  INVALID 
Indicated.  Data  word  reception  continues. 

l.  Invalid  Command  This  bit  shall  be  set  to  logic  1  by  the 
Remote  BCIU  after  receiving  a  mode  command  In  which  the  mode  code  designates 
an  Invalid  operation  for  the  BCIU. 

3. 1.1. 1.2. 7  Status  Code  Register  (SCR) 

This  register  shall  be  used  In  Remote  Mode  only  and  shall  be 
set  and  reset  by  the  Remote  Mode  Processor.  The  actual  status  code  shall  be 
the  nine  (9)  least  significant  bits  of  the  register  and  shall  be  merged  Into 
any  status  word  prior  to  status  word  bus  transmittal  by  the  Remote  BCIU. 

3. 1.1. 1.2. 8  Master  Function  Register  (MFR) 

This  register  shall  be  used  only  In  support  of  the  Master  Func¬ 
tion  Mode  Command.  In  Master  Mode  and  In  accordance  with  Master  Function 
processing,  the  contents  of  the  register  shall  be  transmitted  to  the  Remote 
device  as  a  data  word  Immediately  following  the  command  word.  It  shall  be 
the  Master  Processor's  responsibility  to  set  the  register.  In  Remote  Mode, 
the  Remote  Mode  BCIU  shall  place  the  received  data  word,  In  response  to  the 
Master  Function  mode  command,  Into  the  Master  Function  Register.  It  shall 
be  the  Remote  Processor's  responsibility  to  then  Interpret  the  contents  of 
the  register. 
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3.1.1. 1.2.9  Instruction  Word  Register  1  (IWRI) 

This  register  shall  be  used  In  Master  Mode  only  to  hold  the 
first  half  of  the  current  32-bit  Instruction. 

3.1.1.1.2.10  Instruction  Word  Register  2  (IWR2) 

This  register  shall  be  used  In  Master  Mode  only  to  hold  the 
second  half  of  the  current  32-1bt  Instruction. 

3.1.1.1.2.11  Xmlt  Status  Word  Register  (XSWR) 

This  register  shall  be  used  In  Master  Mode  only  to  hold  any 
status  word  received  from  a  Remote  Device  In  Transmit  Mode,  in  which  the 
Message  Error,  Terminal  Failure,  or  Status  Code  fields  were  non-zero. 

3.1.1.1.2.12  Received  Status  Word  Register  (RSWR) 

This  register  shall  be  used  in  Master  Mode  only  to  hold  any 
status  word  received  from  a  Remote  device  in  Receive  Mode,  In  which  the 
Message  Error,  Terminal  Failure,  or  Status  Code  fields  were  non-zero. 

3.1.1.1.2.13  Mode  Data  Register  (MDR) 

In  Master  Mode,  and  only  In  accordance  with  performing  a  cer¬ 
tain  class  of  mode  commands,  the  contents  of  this  register  shall  be  trans¬ 
mitted  to  the  Remote  device  as  a  data  word  immediately  following  the  comnand 
word.  The  Master  Processor  shall  be  responsible  for  setting  the  register. 

In  Remote  Mode,  the  MDR  shall  be  undefined  for  the  Mode  Operation  defined. 

3.1.1.1.2.14  Pointer  Register  (PR) 

This  register  shall  be  set  by  a  BCIU  operating  In  either  Master 
or  Remote  mode  and  shall  contain  the  Initial  data  area  address  for  a  given 
data  bus  operation  Involving  main  memory  data  transfers.  The  register  shall 
be  used  in  Tag  Word  Operations. 
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3.1.1.1.2.15  Data  Address  Register  f PAR) 

This  register  shall  be  set  by  a  BCIU  operating  In  either 
Master  or  Remote  mode  and  shall  be  used  to  Indicate  the  main  memory  address 
of  the  next  data  word  to  be  fetched/stored  In  support  of  a  given  bus  opera¬ 
tion.  The  register  shall  be  derived  from  the  Pointer  Register  and  In  all 
cases  (Receive  or  Transmit)  that  value  shall  be  initially  Incremented  by  1 
to  get  over  the  Tag  Word.  This  value  then  becomes  the  address  to  fetch/store 
the  first  data  word.  As  each  word  Is  fetched/stored,  the  BCIU  shall  Incre¬ 
ment  the  register  value  by  1  to  affect  sequential  data  word  fetch/stores. 

3.1.1.1.2.16  Word  Count  Register  (WCR) 

This  register  shall  be  derived  from  the  Bus  Command  and  set 
by  the  BCIU  in  either  Master  or  Remote  Mode.  In  Bus  Operations  Involving 
data  word  transfers,  it  shall  Indicate  the  remaining  number  of  data  words 
to  be  transferred.  The  register  shall  be  decremented  by  1,  by  the  BCIU,  as 
each  data  word  transfer  is  performed. 

3. 1.1. 1.3  Interrupt  Generation 

The  BCIU  shall  examine  the  Program  Controlled  Interrupt  Indica¬ 
tor  within  the  Instruction  Word  One  Register  (IWR1).  If  set  to  logic  1,  the 
BCIU  shall  set  the  PCI  Indicator  within  the  ISR  to  logic  1.  (see  Figure 
3  ).  The  BCIU  shall  begin  to  examine  the  contents  of  the  ISR 

from  right  to  left,  one  field  at  a  time.  If  any  field  is  found  to  be  non¬ 
zero,  the  BCIU  shall  discontinue  the  examination  and  present  the  correspond¬ 
ing  level  Interrupt  ss  indicated  In  Figure  3. 

3.1. 1.2  Remote  Terminals 

3. 1.1. 2.1  Basic  Characteristics 

The  Remote  Terminal  (RT)  provides  the  interface  between  the 

IDAMST  Multiplex  System  and  an  Aircraft  Subsystem. 

The  RTs  provide  for  Bus  communication  with  the  IDAMST 
processors  (as  described  In  Section  3. 1.1. 1.2). 
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The  subaddress  field  of  each  Transmit  or  Receive  Command  acts 
as  a  message  Identifier.  The  message  Is  formatted  by  the  RT  for  correct  In¬ 
terface  with  the  Interface  Modules  (IM)  which  relay  (or  accept  from)  the  sig¬ 
nals  to  the  aircraft  subsystems. 

< 

The  RT  also  as  a  buffer,  holding  the  message  until  correct 
transmission  has  occurred. 

The  RT  performs  all  the  error  checking  and  setting  of  error 
and  status  bits  of  a  remote  BCIU. 

3. 1.1. 2. 2  RT  Functions 

The  RT  shall  contain  the  registers,  logic,  decoders,  buffers, 
comparators  and  control  sequences  required  to  perform  the  following  functions 

a.  Receive  Command  Words  from  the  Bus. 

b.  Detect  Command  Words  directed  to  this  RT. 

c.  Receive  Data  Words  from  the  Bus  (one  at  a  time)  If  directed 
to  do  so  by  the  received  Command  Word. 

d.  Transmit  Data  Words  through  the  Bus  to  the  data  bus  (one  at 
a  time)  If  directed  to  do  so  by  the  received  Command  Word. 

e.  Transmit  Status  Words  through  the  Bus  to  the  data  bus  as 
directed  by  the  received  Command  Word. 

f.  Perform  Mode  Operations  when  and  as  directed  by  received 

Command  Words. 

g.  Distribute  received  Data  Words  to  the  proper  channels  of 

the  proper  IMs. 

h.  Input  Data  Words  from  the  proper  channels  of  the  proper  IMs 
for  transmission  to  the  data  bus. 

1.  Maintain  the  Status  Word  and  the  Built-in-Test  (BIT)  Word 
of  the  RT  by  performing  continuous  and  periodic  self  test  functions  within 
the  RT. 

j.  Maintain  an  Activity  Word  and  Error  Word  for  monitoring 
status  of  serial  digital  IM's. 
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k.  Maintain  a  Last  Command  Register  for  verification  of  com¬ 
mand  receipt  In  the  event  of  an  Invalid  response. 

l.  Perform  Bit  and  Word  Masking. 

3. 1.1. 3  Processor  Control  Panel  (PCP) 

The  IDAMST  Processor  Control  Panel  Is  Illustrated  In  Figure  5 
and  Its  description  follows. 

3. 1.1. 3.1  IDAMST  Bus  Power  Switches 

The  function  of  these  switches  Is  to  provide  the  required  sig¬ 
nal  to  the  power  control  unit  to  turn  on  and  off  the  power  supplied  to  the 
multiplex  elements  (Remote  Terminal  side  A  and  B,  and  the  Bus  Control  Inter¬ 
face  Units).  These  switches  shall  also  control  power  to  all  other  processor 
control  panel  functions.  These  switches  shall  be  push-on,  push-off,  and 
backlighted  to  Indicate  the  "on"  condition. 

3. 1.1. 3. 2  Processor  Power  Switches 

The  function  of  these  switches  Is  to  provide  the  control  sig¬ 
nal  to  the  power  control  unit  to  turn  on  or  off  each  processor.  One  switch 
shall  be  supplied  for  each  processor.  The  processor  "power  on"  signal  shall 
also  be  supplied  to  the  advisory  caution  panel  circuitry  to  control  the  pro¬ 
cessor  failure  Indication.  The  switches  shall  be  push-on,  push-off  and  back¬ 
lighted  as  described  below. 

3. 1.1. 3. 3  Processor  Interrupt  -  Startup/Restart 

This  switch,  when  depressed,  shall  enable  the  startup/restart 
Interrupt  to  each  Processor.  The  processor  shall  enter  the  Startup/Loader 
program  and  perform  complete  system  restart  as  defined  In  the  System  Control 
Procedures.  This  switch  shall  be  a  momentary  switch  and  backlighted  while 
depressed. 


3. 1.1. 3. 4  Processor  Interrupt  -  Reconfiguration 

This  switch,  when  depressed,  shall  enable  the  reconfigure  In¬ 
terrupt  to  each  Processor  and  cause  the  Master  Executive  performing  system 
control  (either  Master  Executive  In  Master  Processor  or  Monitor  Processor)  to 


Figure  5  -  IDAMST  Processor  Control  Panel  (PCP) 


Initiate  reconfiguration.  Reconfiguration  Is  performed  after  one  or  more 
processors  have  failed;  the  system  Is  In  either  the  recovery  or  backup  mode; 
and  the  pilot  manually  Initiates  reconfiguration. 


3.1. 1.3. 5 


PCP. 


Press  to  Test 

The  function  of  this  switch  shall  be  to  test  all  lights  on  the 


3. 1.1. 3. 6  Switch  Indicators 

3. 1.1. 3. 6.1  IDAMST  BUS  Power  and  Processor  Interrupts 

These  switches  shall  be  backlighted  to  Indicate  the  "on"  con¬ 
dition. 

3. 1.1. 3. 6. 2  Processor  Power 

These  switches  shall  be  backlighted  as  follows: 

a.  White  -  Indicates  the  switches  have  been  depressed 

b.  Green  -  Indicates  ("GO")  that  power  has  been  supplied 

to  the  processor  and  the  "Processor  GO/NO-GO"  signal  has  been  set  to  the  "GO" 
state  within  the  previous  40  msec. 


c.  Red  -  Indicates  ("Fall")  processor  power  Is  "on" 
and  the  absence  of  the  "GO"  signal  for  more  than  40  msec. 

3.1.2  Software  Interfaces 

The  IDAMST  Executive  software  Interfaces  with  the  Application 
software  developed  for  IDAMST  and  a  pre-processor  software  system  (PALEFAC) 
that  allocates  and  Initializes  the  executive  tables. 


The  IDAMST  Application  Software  has  been  defined  to  consist 
of  Events,  Tasks,  Comsubs,  Compool  Blocks  and  Real-Time  Pseudo  Statements. 
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Tasks  and  Comsubs  are  processing  modules  containing  executable 
code  and  local  data.  Compool  Blocks  and  data  modules  used  for  communication 
between  tasks.  Events  are  boolean  values  used  for  control  Interactions  be¬ 
tween  tasks. 

Real-Time  Pseudo  Statements  are  the  means  through  which  the 
Application  Software  will  communicate  with  the  Executive. 

3. 1.2.1  Events 

Events  are  used  for  control  communication  between  tasks.  An 
event  has  two  possible  values:  on  and  off. 

Any  Task  may  have  an  associated  Task  Activation  Event.  Such 
an  Event  is  set  on  when  the  Task  is  Activated  and  set  off  when  the  Task  re¬ 
turns  to  Inactive  or  Uninvoked  state.  The  Activation  Event  associated  with 
a  Task  must  have  the  same  name  as  the  Task. 

Any  Compool  Block  may  have  an  associated  Compool  Update  Event. 
Such  an  Event  Is  set  on  when  the  Compool  Block  Is  updated,  either  by  a  Task 
or  an  RT.  The  Update  Event  associated  with  a  Compool  Block  must  have  the 
same  name  as  the  Compool  Block. 

Minor  Cycle  Events  are  set  on  by  the  Executive  according  to 
specified  rates  and  phases.  They  may  only  be  referenced  in  Event  Condition 
Sets. 

3. 1.2. 2  Tasks 

Tasks  are  the  principal  processing  module  within  the  IDAMST 
Application  software.  All  tasks  have  been  defined  to  exist  In  a  given  "state" 
at  a  given  time.  These  "states”  are  Illustrated  In  Figure  6.  The 

"states"  of  tasks  are  controlled  by  the  application  software  through  the 
Real-Time  Pseudo  Statements  (see  Paragraph  3. 1.2. 5).  A  task  shall  become 
"invoked"  only  after  being  scheduled  by  another  task,  otherwise  It  shall 
remain  uninvoked. 
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Immediately  after  being  scheduled,  a  Task  Is  Inactive;  how¬ 
ever,  It  has  the  potential  to  become  Active,  depending  upon  Its  Event  Condi¬ 
tion  Set.  The  Event  Condition  Set  Is  a  collection  of  Conditions,  each  of 
which  may  be  either  "on"  or  "off."  Each  Condition  has  a  "desired"  value. 

When  all  the  conditions  In  the  Event  Condition  Set  have  their  desired  values. 
If  the  Task  Is  Inactive,  the  Executive  will  put  It  Into  Active  state.  A 
Task  may  have  a  null  Event  Condition  Set,  In  which  case  It  can  only  be  In¬ 
active  momentarily. 

Each  Condition  In  an  Event  Condition  Set  Is  associated  with  a 
set  of  Events.  When  any  of  these  Events  Is  set  on,  the  Condition  Is  set  on; 
when  any  of  these  Events  Is  set  off,  the  Condition  Is  set  off.  One  Event 
may  be  associated  with  more  than  one  Condition  In  an  Event  Condition  Set. 

In  addition,  one  Condition  may  be  associated  with  a  "Minor  Cycle  Event." 

These  are  Executive-generated  Events  which  are  set  "on"  at  certain  specified 
times  and  are  otherwise  Inaccessible  to  the  Application  Soft¬ 

ware.  If  a  Condition  Is  associated  with  a  Minor  Cycle  Event,  It  may  not  be 
associated  with  any  other  Event. 

A  Condition  may  be  either  Latched  or  Unlatched.  A  Condition 
associated  with  a  Minor  Cycle  Event  must  be  Unlatched.  The  sole  difference 
between  a  Latched  and  an  Unlatched  Condition  is  that  upon  the  Scheduling  or 
Activation  of  a  Task,  the  Unlatched  Conditions  are  set  to  the  undesired 
value.  Thus,  a  Task  can  only  be  Activated  by  an  Unlatched  Condition  when  the 
value  of  that  condition  Is  changed  to  the  desired  value  subsequent  to  the 
last  Scheduling  or  Activation  of  the  Task.  By  contrast.  Latched  Conditions 
are  changed  only  when  one  of  their  associated  Events  Is  changed.  Therefore, 
a  Task  with  only  Latched  Conditions  In  its  Condition  Set  will  be  Immediately 
Activated  after  It  Is  Scheduled  If  all  the  Conditions  were  satisfied  before 
the  Schedule  Statement. 

A  Task  may  return  from  Active  to  Inactive  state  from  two 
causes:  either  because  It  completes  execution,  or  because  It  Is  forcibly 
Terminated  by  another  Task.  In  either  case.  Immediately  after  It  returns  to 
Inactive  state,  the  Event  Condition  Set  Is  evaluated,  and  If  all  the  Condi - 
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tlons  have  their  desired  values,  the  Task  Is  Immediately  re-activated. 

When  a  Task  Is  Activated,  It  Is  Immediately  put  Into  DIs- 
patchable  state.  If,  at  any  point  during  Its  execution,  a  Task  executes  a 

Walt  Statement,  the  Executive  will  place  it  Into  Walt  state  until  the  sped- 

» 

fled  condition  Is  satisfied,  upon  which  the  Task  will  again  become  Dispatch- 
able. 

All  Dlspatchable  Tasks  should  theoretically  be  executed  Immed¬ 
iately.  However,  since  there  may  be  more  than  one  Dlspatchable  Task  at  any 
time  within  any  one  of  the  DAIS  Processors,  Tasks  are  ordered  by  Priority  to 
resolve  possible  conflicts.  Whenever  the  Executive  in  any  Processor  Is  not 
called  upon  for  immediate  action.  It  selects  the  highest  Priority  Dlspatch¬ 
able  Task,  and  causes  the  Processor  to  execute  It. 

Some  tasks  are  declared  "Privileged  Tasks"  and  are  considered 
to  have  the  highest  priority.  Thus,  as  soon  as  they  are  scheduled  and  their 
Event  Condition  Set  Is  satisfied,  they  immediately  become  executable  with 
the  highest  priority. 

If  a  Task  Is  Active  but  has  not  yet  been  executed,  it  Is  said 
to  be  Ready.  If  It  has  been  In  the  process  of  execution,  but  has  been  In¬ 
terrupted  by  a  higher  priority  Task,  It  Is  said  to  be  Suspended.  If  It  Is 
executing.  It  Is  said  to  be  Executing. 

Any  given  Task  may  only  be  Scheduled  by  one  Task,  which  Is 
called  Its  Controller.  Two  Tasks  with  a  common  Controller  are  said  to  be 
"siblings."  The  Tasks  Scheduled  by  any  Task  are  said  to  be  Its  "sons."  If 
a  Task  has  no  sons.  It  Is  said  to  have  no  "descendents;"  otherwise.  Its 
descendents  are  its  sons  and  all  the  descendents  of  Its  sons. 

Only  a  Task's  Controller  may  Cancel  or  Terminate  it;  however, 
when  a  Task  is  Cancelled  or  Terminated,  all  of  Its  descendents  are  Cancelled 
or  Terminated.  If  a  Task  attempts  to  Cancel  or  Terminate  Itself,  It  will 
Cancel  or  Terminate  all  of  Its  descendents,  but  will  leave  Its  own  state 
unchanged. 


3. 1.2. 3  Corns ubs 

In  addition  to  Tasks,  the  IDAMST  Application  Software  may  In¬ 
clude  another  kind  of  processing  module,  known  as  the  "Comsub.“  A  Corns ub 
Is  a  Jovial  J73/I  based  procedure  declared  external  to  any  Tasks.  A  Cornsub 
may  be  called  from  many  Tasks;  there  is  a  copy  of  each  Cornsub  In  any  proces- 
so r  containing  a  Task  from  which  the  Cornsub  may  be  called. 

A  Cornsub  communicates  with  a  Task  which  calls  It  only  through 
Its  parameters  and/or  function  result.  No  Cornsub  may  execute  any  Real-Time 
Pseudo-Statements;  however,  one  Cornsub  may  call  another. 

When  a  Task  calls  a  Cornsub,  the  Task  Is  considered  to  be  exe¬ 
cuting  within  the  code  of  the  Cornsub.  Thus,  It  is  possible  for  one  Task  to 
be  suspended  within  the  code  of  a  Cornsub  at  the  same  time  that  another  Task 

Is  executing  within  the  same  Cornsub.  In  other  words,  a  Cornsub  must  be  re¬ 

entrant.  To  implement  this,  every  Task  has  a  Cornsub  Local  Storage  Area 
assigned  by  PALEFAC  for  storage  of  local  data  by  the  Comsubs  which  It  calls. 

At  any  time,  there  Is  a  Cornsub  Stack  Pointer  which  points  to  the  area  avail¬ 
able  for  storage  to  the  next  called  Cornsub.  This  Cornsub  Stack  Pointer  is 

considered  to  be  part  of  the  process  state  of  the  Task,  and  is  saved  upon  the 

occurrence  of  an  Interrupt. 

3. 1.2.4  Compool  Blocks 

All  communication  of  data  between  Tasks  or  between  Tasks  and 
the  external  environment  (RT's)  Is  done  by  means  of  "Compool  Blocks." 

No  Task  may  directly  access  a  Compool  Block;  Instead,  a  Task 
references  a  "Local  Copy"  which  has  size  and  attributes  Identical  to  the  Corn- 
pool  Block.  A  Task  may  copy  the  Compool  Block  into  Its  Local  Copy  by  a  READ 
Statement,  or  copy  the  Local  Copy  Into  the  Compool  Block  by  a  WRITE  statement. 
From  the  point  of  view  of  the  Application  Software,  READS,  WRITES,  occur  In¬ 
stantaneously,  so  a  Compool  Block  can  never  be  read  when  It  has  been  partially 
updated  by  a  WRITE. 


Compool  Blocks  are  divided  Into  three  classes:  Input,  Output, 
and  Inter- task.  Input  Compool  Blocks  can  only  be  accessed  by  Tasks  In  a  READ 
statement.  Their  values  are  determined  by  RT’s.  Output  Compool  Blocks  can 
only  be  accessed  by  Tasks  in  a  WRITE  statement;  their  values  are  "received" 
only  by  RT's.  Intertask  Compool  Blocks  are  used  solely  for  communication  be¬ 
tween  Tasks. 


Since  a  Compool  Block  may  be  accessed  In  more  than  one  pro¬ 
cessor  and  also,  possibly.  In  an  RT,  Compool  Blocks  may  exist  In  multiple 
copies.  Any  processor  In  which  a  Compool  Block  Is  read  has  a  Physical  Copy 
of  the  Block;  any  RT  which  references  the  Block,  or  any  processor  which  only 
WRITES  the  Compool  Block,  is  considered  to  have  a  Virtual  Copy  of  the  Block. 
To  maintain  consistency  between  the  various  copies  of  a  Compool  Block,  the 
Executive  must  send  Compool  Update  Messages  across  the  Data  Bus.  Compool 
Blocks  are  further  classified  according  to  when  these  Update  Messages  are 
sent  as:  Synchronous,  and  Asynchronous. 

Synchronous  Compool  Blocks  are  updated  from  a  single  authori¬ 
tative  Copy,  whether  In  a  processor  or  an  RT,  at  a  specified  rate  and  phase. 
All  copies  of  an  Asynchronous  Compool  Block  are  updated  when  any  of  those 
copies  is  changed,  either  by  the  hardware  of  an  RT  or  by  a  WRITE  statement 
within  a  processor. 

3. 1.2. 5  Real-Time  Pseudo  Statements 

The  application  software  requests  services  from  the  Executive 
system  through  Real-Time  Pseudo  Statements.  These  pseudo- statements  are  In¬ 
terpreted  by  the  Executive  software  Into  calls  to  different  functions  as  ex¬ 
plained  in  Section  3. 2. 1.3.  The  statements  Implemented  In  the  IDAMST  system 
are: 

a.  SCHEDULE 

b.  CANCEL 

C.  TERMINATE 

d.  WAIT 

e. .  SIGNAL 

f.  WRITE 

g.  READ 
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3. 1.2. 6  Palefac 

The  PALEFAC  software  system  Is  responsible  for  the  allocation 
and  Initialization  of  the  Executive  Tables  driving  the  IDAMST  Executive  soft¬ 
ware.  These  tables  describe  the  attributes  and  Inter-relations  of  the  vari¬ 
ous  components  of  the  application  software,  l.e. ,  tasks,  events,  compool 

t 

blocks,  comsub. 


PALEFAC  shall  generate  two  types  of  executive  tables:  Local 
Executive  Tables  and  Master  Executive  Tables.  The  Local  Executive  Tables  are 
used  for  control  of  Tasks,  Events,  Compool  Blocks  and  Comsub.  The  Master 
Executive  Tables  are  used  by  the  Master  Executive  to  control  the  operations 
of  the  master  processor  and  Its  Interface  with  the  master  BCIU. 

These  tables  have  been  described  extensively  In  Section  3.2 
and  have  been  Identified  with  the  particular  function  Involved  with  the  data. 

3.2  Detailed  Functional  Requirements 

3.2.1  IDAMST  Local  Executive  Functions 

The  IDAMST  local  Executive  shall  reside  In  each  processor 
within  the  IDAMST  federated  system  and  It  shall  be  functionally  Identical  In 
each  processor. 


The  functions  of  the  Local  Executive  shall  be  to: 

1.  Perform  services  as  requested  by  the  application  software. 
These  services  are: 

a.  Event  signalling 

b.  Task  scheduling 

c.  Task  termination 

d.  Task  cancellation 

e.  Walt 

f.  Compool  Read/Write 
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2.  Perform  event  handling,  and  task  checking  and  dispatching. 


3.  Control  the  Interface  with  the  BCIU  with  regard  to  Local 
Executive  Communications. 

i 

4.  Respond  to  minor  cycle  interrupt  and  participate  In  the 
transmission  and  reception  of  synchronous  messages. 

5.  Participate  In  asynchronous  message  transmission  and 

reception. 


Figure  7  illustrates  the  functions  interrelation¬ 

ship. 

Figure  8  illustrates  a  top  level  functional  flow 

as  exercised  by  the  IDAMST  Local  Executive. 

3. 2. 1.1  Function  One  -  Local  Executive  Control 

The  purpose  of  this  function  is  to  provide  single  point  con¬ 
trol  of  the  Local  Executive  by  maintaining  the  proper  sequencing  of  Its  func¬ 
tions.  The  Local  Executive  Control  processes  requests  from  the  Application 
Software  Interface  and  the  Hardware  Interface  Functions. 

3. 2. 1.1.1  Inputs  to  the  Local  Executive  Control  Function 
Inputs  are  listed  In  Table  II. 

In  order  to  Identify  messages  received  from  Remote  Terminals, 
two  tables  of  predetermined  Information  are  used.  These  are  called  the  Ter¬ 
minal  Originator  Address  Table  (TOAD)  and  the  Subaddress  Name  Keys  Table 
(SNAKE). 


3. 2. 1.1. 1.1  Terminal  Originator  Address  Table  (TOAD) 

This  table,  Illustrated  In  Figure  9  shall  appear  once 
In  every  processor.  An  entry  In  this  table  is  generated  for  each  of  the  32 
possible  Remote  Terminals.  Thus,  the  RT  address  Is  to  Index  Into  this  table. 
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Figure  8  -  LOCAL  EXECUTIVE  FUNCTIONAL  FLOW 


ITEM 

DESCRIPTION 

1 

Number  of  Asynchronous  Messages  from  this  RT 

2 

Pointer  to  First  Message  described  in  SNAKE 

Table  (Fig.  3. 2. 1.1-2) 

o  This  table  to  contain  one  entry  for  each  of  the  32  possible 

Remote  Terminals 

Figure  9 


Terminal  Origination  Address 
Table  (TOAD)  Description 


2 


MV. ..  0&A ies 


This  table  shall  specify  the  number  of  synchronous  messages  associated  with 
the  RT  and  shall  provide  a  pointer  to  the  message  descriptions  located  In 
the  Subaddress  Name  Keys  Table.  If  there  are  no  messages  originating  from 
this  RT,  Its  entry  In  this  table  shall  be  null. 

t 

3. 2. 1.1. 1.2  Subaddress  Name  Keys  Table  (SNAKE) 

This  table.  Illustrated  In  Figure  10  shall  appear  once 
In  every  processor.  It  shall  contain  an  entry  for  each  possible  asynchron¬ 
ous  message  from  the  remote  terminals  to  the  processor.  All  messages  from 
an  RT  shall  be  contiguous  within  this  table  and  they  shall  be  Indexed  by  the 
pointer  stored  In  TOAD  (ref.  para.  3. 2. 1.1. 1.1)  and  Identified  by  the  sub¬ 
address  accompanying  the  RT  message. 

3. 2. 1.1. 2  Local  Executive  Control  Processing 

This  function  controls  the  sequence  of  operations  performed 
by  the  Local  Executive.  These  operations  are  a  consequence  of: 

a.  The  reception  and  processing  of  a  minor  cycle 
(synchronous)  Interrupt. 

b.  A  service  request  originating  in  an  application  or 
Executive  Task. 

c.  The  processing  of  an  Asynchronous  Reception. 

d.  The  performance  of  System  Initialization. 

Figure  11  demonstrates  the  Local  Executive  Control 
Processing  sequence. 

Upon  being  entered,  the  Function  will  determine  If  a  minor- 
cycle  set-up  Is  due.  If  a  minor-cycle  set-up  is  not  pending  the  Event  Queue 
Is  Immediately  searched.  After  the  Local  Executive  Control  Function  de¬ 
queues  an  Event  from  the  Event  Queue,  control  is  passed  to  the  Event  Hand¬ 
ling  Function. 
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ITEM 

DESCRIPTION 

1 

RT  sub-address  originating  the  message 

2 

Pointer  to  Asynchronous  DDB  for  this  message 

(ref.  para.  3. 2. 1.3.1) 

o  This  table  to  contain  an  entry  for  each  possible 

asynchronous  message  from  RT's. 

Figure  10  Sub-address  Name  Keys  Table  (SNAKE) 
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Figure  11 


LOCAL  EXECUTIVE  CONTROL  PROCESSING 
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V.  • 


If  an  asynchronous  reception  Is  pending  In  the  Reception 
Queue,  the  Asynchronous  ID  Is  decoded,  and  the  proper  function  Is  Invoked 
accordingly.  If  the  asynchronous  message  was  sent  by  a  Remote  Terminal  (RT), 
the  Executive  Tables  associated  with  the  Remote  Terminal  are  examined.  These 
tables,  as  described  In  Section  3. 2. 1.1.1,  specify  the  Data  Descriptor  Block 
associated  with  the  RT.  If  the  source  of  the  asynchronous  message  Is  not  an 
RT,  the  type  of  message  and  the  parameters  to  pass  to  the  specified  function 
are  determined  from  the  ID.  The  types  of  Asynchronous  ID's,  the  Functions 
Invoked  to  service  them,  and  the  parameters  passed  to  those  Functions  are 
listed  In  Table 


After  the  asynchronous  message  Is  processed,  It  Is  dequeued 
from  the  Reception  Queue.  Otherwise,  If  the  processing  had  not  been  accomp¬ 
lished  successfully,  the  ID  would  still  be  available  In  the  Reception  Queue. 

Finally,  the  Task  Dispatching  Function  Is  called. 

The  local  executive  sets  the  Privileged  Mode  flag  when  It  Is 
entered  and  resets  the  flag  before  passing  control  to  a  non- privileged  task. 
The  privileged  mode  flag  Is  used  to  prevent  local  executive  routines  or  "pri¬ 
vileged"  tasks  from  being  re-entered  before  completion.  If  an  interrupt 
occurs  when  the  privileged  mode  flag  is  set,  the  Interrupt  processing  routine 
shall  return  to  the  point  of  interruption  when  It  completes  execution.  Simi¬ 
larly,  when  a  Privileged  Mode  Task  makes  an  Executive  Service  Request,  the 
Local  Executive  shall  return  control  directly  to  the  task. 

3. 2. 1.1. 3  Outputs  from  the  Local  Executive  Control  Functions 

The  actual  output  of  this  Function  Is  the  initiation  of  the 
various  Functions  In  the  exercise  of  the  sequence  control.  Each  one  of  these 
Functions  do  require  several  Inputs  for  their  processing  as  listed  In  the 
description  of  each  specific  function  and  Table  III. 
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3. 2. 1.2  Function  Two  -  Hardware  Interface  Control  Function 

The  Hardware  Interface  Control  Function  shall  have  as  Its 

prime  objective  the  proper  conduction  of  cownunl cation  between  the  Local 
Executive  and  the  Bus  Control  Interface  Unit  (BCIU).  This  communication 
shall  be  accomplished  through  the  reading  and  loading  of  the  BCIU  registers. 

This  Function  shall  be  responsible  to  process  all  Interrupts 
received  from  the  BCIU  and,  as  a  consequence.  Invoke  the  proper  functions 
to  service  the  interrupts.  It  shall  accept  asynchronous  messages  for  trans¬ 
mission,  supply  the  Local  Executive  with  asynchronous  messages  received  and 
accept  and  enqueue  minor  cycle  numbers  as  a  result  of  a  synchronous  inter¬ 
rupt  reception. 


Interrupts  received  as  a  result  of  terminal  failure  or  Data 
communication  error  shall  cause  the  Invocation  of  the  Error/Failure  Control 
Function. 

3. 2. 1.2.1  Inputs  to  Hardware  Interface  Control  Function 

The  inputs  to  this  Function  are  listed  in  Table  IV 

3. 2. 1.2. 1.1  BCIU  Registers 

The  BCIU  registers  referred  to  In  Table  IV  are  listed 
In  Table  I  and  described  in  Paragraph  3. 1.1. 1.2. 


3. 2. 1.2. 1.2  BCIU  Interrupts 

The  BCIU  activates  six  levels  of  interrupts  directly  related 
to  the  contents  of  Internal  Status  Register  (ISR).  As  described  in  Para¬ 
graph  3. 1.1. 1.3,  asynchronous  message  transmission  and  reception  are  related 
to  Level  2  Interrupts.  The  Master  Function  and  the  reception  of  synchronous 
transmission  Is  related  to  Level  3  Interrupt. 


Power-On  Initialization  generates  a  Level  1  interrupt. 
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3.2. 1.2.2  Hardware  Interface  Control  Function  Processing 

The  Hardware  Interface  Control  Function  shall  be  Invoked  upon 
the  reception  of  an  interrupt  from  the  BCIU.  This  function  shall  Invoke  the 
proper  Local  Executive  function  to  service  the  Interrupt.  This  processing  Is 
Illustrated  In  Figure  12. 

If  the  "Privileged  Task  Mode"  flag  is  set,  the  status  of  the 
processor  (program  counter,  registers,  condition  status,  etc.)  prior  to  the 
Interrupt  Is  locally  saved  to  allow  for  immediate  return  after  the  Interrupt 
Is  serviced.  If  the  "Privileged  Task  Mode"  flag  Is  not  set,  the  processor 
status  is  saved  in  the  Local  Processor  Tasks  Table  B  entry  for  the  Interrup¬ 
ted  task. 


The  origin  of  the  interrupt  Is  identified,  if  necessary, 
reading  the  Internal  Status  Register  (ISR)  of  the  BCIU.  Then,  the  appropri¬ 
ate  Executive  Function  Is  Invoked  to  service  the  interrupt,  namely,  asyn¬ 
chronous  reception,  asynchronous  transmission  or  the  Error/Failure  Control 
Function. 


Upon  return,  the  "Privileged  Task  Mode"  flag  is  checked.  If 
It  is  on,  the  processor  will  return  to  the  state  prior  to  the  interrupt. 
Otherwise,  return  will  be  through  Function  1,  Local  Executive  Control  and 
eventually  the  Dispatcher. 

3.2. 1.2. 3  Hardware  Interface  Control  Function  Outputs 

On  exiting  this  function,  the  only  parameter  actually  output 
by  this  function  Is  the  Minor-Cycle  Pending  Flag. 

All  other  outputs  Indirectly  concerned  with  this  Function 
shall  be  output  by  the  Functions  being  Invoked. 
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Figure  12 


Interrupt  Handling  Processing 
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3. 2. 1.3  Function  Three  -  Application  Software  Interface 

Control  Functions 

This  function  serves  as  an  interface  between  the  application 
software  and  the  executive  services.  Each  service  Is  initiated  by  explicit 
task  action  through  the  exercise  of  the  Real  Time  Pseudo- Statements.  In¬ 
cluded  In  the  category  of  local  executive  servlcessare  the  following: 

1.  Task  scheduling 

2.  Task  termination  and  task  cancellation 

3.  Event  signalling 

4.  Compool  read/write 

5.  Walt  -  Absolute  Time 

-  Relative  Time 

-  Latched  Event 

-  Unlatched  Event 

Upon  termination  of  the  executive  service,  an  Executive  Ser¬ 
vice  Return  Function  shall  be  activated.  This  function  determines  whether 
control  must  be  relinquished  to  the  calling  task  or  more  executive  functions 
need  to  be  exercised. 

3. 2. 1.3.1  Inputs  to  Application  Software  Interface  Control  Function 

The  Inputs  to  the  local  executive  services  function  are  listed 
In  Table  V.  The  source  of  these  inputs  Is  the  requesting  applica¬ 

tion  or  executive  task. 

Task  Table  A  and  Data  Descriptor  Blocks  are  preloaded  tables. 
Their  description  follows. 

Task  Table  A 

This  table  is  illustrated  In  Figure  13.  This  table 

shall  appear  once  In  every  processor.  It  shall  contain  an  entry  for  any 
task  residing  In  the  processor  and  for  the  controller  and  sons  of  this  task, 
whether  resident  In  this  processor  or  not. 
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TABLE  V 


ROUTINE 


SCHEDULE 

CANCEL 

TERMINATE 

EVENT 

SIGNALLING 

COMPOOL 


COMPOOL 

WRITE 


INPUTS  TO  APPLICATION  SOFTWARE  INTERFACE  CONTROL  FUNCTION 


INPUT  PARAMETERS 


1.  TASK  TABLE  A  ENTRY  OF  TASK  TO 
BE  SCHEDULED 

1 .  TASK  TABLE  A  ENTRY  OF  TASK  TO 
BE  CANCELLED 

1.  TASK  TABLE  A  ENTRY  OF  TASK  BEING 
TERMINATED 

1.  DESIRED  EVENT  VALUE 

2.  EVENT  TABLE  ENTRY 

(REF.  TABLE  VII  ) 

1.  COMPOOL  BLOCK  DDB  ADDRESS 

2.  LOCAL  STORAGE  INTO  WHICH  EACH 
COMPOOL  BLOCK  IS  TO  BE  READ 

1 .  COMPOOL  BLOCK  DDB  ADDRESS 

2.  LOCAL  AREA  TO  BE  WRITTEN  FROM 


SOURCE 


REQUESTING 

TASK 


WAIT: 

ABSOLUTE  TIME  1 .  ABSOLUTE  TIME 

RELATIVE  TIME  2.  RELATIVE  TIME 

LATCHED  EVENT  1.  DESIRED  EVENT  VALUE 

2.  EVENT  TABLE  ENTRY 

UNLATCHED  EVENT  1.  DESIRED  EVENT  VALUE 

2.  EVENT  TABLE  ENTRY 

(REF.  TABLE  VII) 


LATCHED  EVENT 


W 


*--i  w*  t  i 
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Task  Table  A  shall  be  ordered  according  to  the  invocation 
tree,  according  to  the  following  rules: 

a.  The  controller  of  a  task  always  precedes  the  task. 

b.  If  Tasks  A  and  B  are  siblings  and  A  precedes  B,,and  A  Is 
not  the  controller  of  B,  then  all  offsprings  of  A  precedes  B. 

Asynchronous  Data  Descriptor  Block  (DDB) 

Every  physical  or  virtual  copy  of  a  compool  block  within  a 
processor  has  an  associated  DDB.  An  asynchronous  DDB  area  shall  appear  once 
in  every  processor.  An  asynchronous  DDB  is  generated  for  each  compool  block 
that  is  read,  written  or  updated  by  a  task  in  this  processor. 

Figure  14  illustrates  the  components  of  an  asynchronous 

DDB. 

Item  #1:  Is  off  because  this  is  an  Asynchronous  DDB. 

Item  #2:  Is  on  if  there  is  a  physical  copy  of  this  compool 
block  within  this  processor.  This  item  indicates  whether  Item  #7  is  present. 

Item  #3:  Is  on_  if  there  is  an  Update  Event  for  this  compool 
block  within  the  processor.  This  item  indicates  whether  Item  #8  is  present. 
Note  that  this  item  can  be  on  only  if  Item  #2  is  on. 

Item  #4:  Is  on_  1 f  there  is  a  virtual  copy  of  this  compool 
block  in  an  RT  and  this  compool  block  is  written  within  this  processor.  This 
item  indicates  whether  Item  #9  is  present. 

Item  #5:  Is  the  number  of  non-local  physical  copies  of  this 
compool  block  to  be  updated  from  this  processor.  It  is  zero  if  the  compool 
block  is  not  written  within  this  processor.  This  item  indicates  the  number 
of  items  of  types  #10  and  #11. 

Item  #6:  Is  the  number  of  words  in  the  compool  block,  includ¬ 
ing  the  MC  Tag  Word. 
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— 

ITEM 

- . — - — 

DESCRIPTION 

1 

NON-RESIDENT  BIT 

2 

PROCESSOR  NUMBER 

3 

INDEX  TO  TASK  TABLE  ENTRY 

4 

NON-RESIDENT  BIT  FOR  CONTROLLER 

5 

PROCESSOR  NUMBER  FOR  CONTROLLER 

6 

INDEX  TO  TASK  TABLE  ENTRY  FOR  CONTROLLER 

7 

INVOKED/UNINVOKED  BIT 

8 

NUMBER  OF  DESCENDANTS 

FIGURE  13  TASK  TABLE  A 


Item  #1:  ON  if  the  task  is  non-resident. 

Item  #2:  Processor  number  where  a  non-resident  task  resides. 

If  the  task  is  resident  to  this  processor,  this 
item  will  be  zero. 


Item  #3: 


Item  #4  -  #6: 


Item  #7: 
Item  #8: 


For  non-resident  task,  pointer  to  task  Table  A  in 
the  appropriate  processor.  For  resident  task,  points 
to  entry  in  Local  Processor  Task  Table  B  (ref.  Table 

X  ). 

Point  to  the  controller  in  the  same  way  that  Items  #1 
-#3  point  to  the  task.  If  this  task  is  the  highest 
task  in  the  hierarchy  tree,  these  Items  will  be  set  to 
zero. 

ON  if  the  task  is  uninvoked. 

The  total  number  of  descendants  of  this  task  with 
entries  in  this  processor's  task  Table  A. 
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ITEM 

DESCRIPTION 

1 

SYNCH  BIT 

2 

LOCAL  COPY  BIT 

3 

UPDATE  EVENT  BIT 

4 

REMOTE  TERMINAL  TRANSMIT  BIT 

5 

NUMBER  OF  NON-LOCAL  PHYSICAL  COPIES 
(INDICATES  NBR.  OF  PAIRS  10,  11) 

6 

NUMBER  OF  WORDS  IN  COMPOOL 

7 

ADDRESS  OF  LOCAL  COPY 

8 

OFFSET  TO  UPDATE  EVENT  IN  EVENT  TABLE 
(TABLE  VII  ) 

9 

REQUEST  VECTOR  FOR  REMOTE  TERMINAL  TRANSMISSION 

,°  » 

OFFSET  TO  DDB  OF  PHYSICAL  COPY  WITHIN  EACH  PROCESSOR 

11  f 

REQUEST  VECTORS  FOR  UPDATING  NON-LOCAL  PHYSICAL  COPIES 

FIGURE  14  ASYNCHRONOUS  DATA  DESCRIPTOR  BLOCK 
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Item  #7:  If  present,  Is  the  starting  address  of  the  local 
physical  copy  of  the  compool  block. 

Item  #8:  If  present.  Is  an  offset  from  the  beginning  of  the 
Event  Table  to  the  entry  for  the  Update  Event  associated  with  this  compool 
block. 


Item  #9:  If  present.  Is  the  Request  Vector  for  updating  the 
virtual  copy  of  this  compool  block  within  an  RT. 

Item  #10:  If  present,  are  offsets  from  the  beginning  of  the 
DDB  area  within  each  processor  with  a  physical  copy  of  this  compool  block 
to  the  DDB  for  that  physical  copy. 

Item  #11:  If  present,  are  the  Request  Vectors  for  sending 
updates  for  non-local  physical  copies  of  this  compool  block. 

Synchronous  DDB 

Synchronous  DDB's  are  used  for  Synchronous  Compool  Blocks.  All 
Synchronous  DDB's  within  a  processor  are  contained  In  a  single  contiguous 
synchronous  DDB  area.  A  synchronous  DDB  area  shall  appear  once  in  every 
processor. 

A  synchronous  DDB  Is  Illustrated  In  Figure  15 

3. 2.1. 3. 2  Application  Software  Interface  Control  Function  Processing 

This  function  consists  primarily  of  a  collection  of  Executive 
Service  Routines.  Whenever  a  task  requests  an  executive  service  by  means  of 
a  Real  Time  Pseudo  Statement,  a  call  to  an  executive  service  routine  is 
effected.  The  return  from  the  service  routing  Is  done  through  this  control 
function  in  order  to  determine  whether  return  should  be  directly  to  the  call¬ 
ing  task  or  to  satisfy  any  other  request  from  the  Local  Executive. 
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ITEM 

DESCRIPTION 

1 

Synchronous  Bit 

2 

Number  of  Words  in  Compool  Block 

3 

Absolute  Address  of  Compool  Block 

4 

Period  -1 

5 

Phase 

Item  #1 :  On  for  a  Synchronous  DDB 

Item  #2:  Number  of  Words  in  Data  Block 

Item  #3:  Starting  Address  of  Compool  Block 

Item  #4:  Number  of  Minor  Cycle  between  successive 

transmission  of  this  block 

Item  #5:  Phase  on  which  the  Compool  Block  is  transmitted 


FIGURE  15  SYNCHRONOUS  DDB 
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3. 2. 1.3. 2.1  Task  Scheduling 

The  Task  Scheduling  Service  shall  be  accomplished  as  illustrated 
in  Figure  16. 


3. 2. 1.3. 2. 2  Task  Termination/ Cancellation 

This  service  shall  forcibly  terminate  or  cancel  a  task,  as  re¬ 
quested,  and  act  upon  the  tasks  descendants. 

When  a  task  Is  terminated,  it  is  put  into  an  Inactive  State;  a 
cancellation  request  will  establish  the  task  as  uninvoked.  A  termination  or 
cancellation  request  may  be  for  self -termination  or  cancellation  or  may 
specify  a  descendant.  A  request  on  a  descendant  shall  also  affect  the  des¬ 
cendant's  descendant.  On  the  other  hand,  a  request  for  self-cancellation  or 
self- termination  shall  be  Interpreted  as  a  request  to  cancel  or  terminate 
only  Its  descendants. 

The  Cancellation/Termination  processing  is  illustrated  in 

Figure  17. 


3. 2. 1.3.2. 3  Event  Signalling 

The  event  signalling  services  requests  to  set  an  event  state  to 
either  "1"  or  "0".  Upon  receipt  of  this  request,  the  proper  event  informa¬ 
tion  will  be  stored  In  the  Event  Queue.  The  Event  Handling  Function  will 
proceed  to  exercise  the  request  as  described  in  paragraph  3. 2. 1.4. 

3.2. 1.3. 2. 4  Wait 

Walt  service  is  requested  by  a  dispatchable  task  to  place  It¬ 
self  into  a  wait  state  until  a  specified  time  occurs  or  a  specified  Event 
attains  a  specified  value. 

An  Absolute  Time  Walt  places  the  task  into  Walt  state  until  a 
specified  absolute  time.  If  the  specified  time  has  already  occurred,  this 
statement  is  a  No-Op. 
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FIGURE  17.  TASK  TERMINATION/ CANCELLATION  PROCESSING 


TERMINATION/CANCELLATION  PROCESSING 


A  Relative  Time  Walt  places  the  task  Into  Walt  state  for  a 
specified  period  of  time.  If  the  specified  period  Is  non-positive,  this 
statement  Is  a  No-Op. 

A  Latched  Walt  places  the  task  Into  Walt  state  until  a  speci¬ 
fied  Event  reaches  a  specified  "desired  value."  If  the  Event  already  has 
the  desired  value,  this  statement  Is  a  No-Op. 

An  Unlatched  Walt  places  the  task  Into  Walt  state  until  the 
specified  Event  Is  changed  to  the  specified  value.  This  statement  Is  never 
a  No-Op. 


This  service  processing  Is  Illustrated  In  Figure  18. 

3. 2. 1.3. 2. 5  Compool  Read/Write 

Compool  blocks,  classified  according  to  when  they  are  updated, 
are  named  Synchronous  and  Asynchronous. 

Synchronous  Data  Blocks  are  updated  from  a  single  authoritative 
copy  at  a  specified  rate  and  phase.  Asynchronous  Compool  Blocks  are  updated 
whenever  any  particular  copy  Is  changed,  either  by  the  hardware  of  an  RT 
or  by  a  WRITE  statement  within  a  processor. 

The  first  word  of  each  physical  and  virtual  copy  of  a  compool 
block  In  a  processor  shall  consist  of  a  "Minor  Cycle  Time  Tag"  Indicating 
the  last  time  the  physical  copy  was  updated.  The  generation  of  this  "Time 
Tag"  has  been  explained  In  Paragraph  3. 2. 1.2. 

Compool  Block  Processing  is  illustrated  in  Figure  19. 

3. 2. 1.3. 2. 6  Executive  Service  Return  Function 

This  function  Is  called  by  all  executive  service  routines  on 
their  way  to  relinquish  control.  As  Illustrated  In  Figure  20,  this 
function  shall  determine  whether  there  Is  a  need  to  perform  additional 
local  executive  functions.  These  additional  functions  could  have  been  as  a 
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SUSPEND 

TASK 


ENABLE  ! 
INTERRUPTS 


CALL  LOCAL 
EXEC.  CONTROL 
(ref.  P.  3.2. 1.1) 


FIGURE  20.'  EXECUTIVE  SERVICE  RETURN  PROCESSING 


result  of  asynchronous  or  synchronous  messages  received  while  executing  the 
executive  services  In  a  privileged  mode  or  the  executive  services  themselves 
requested  further  services. 


The  first  thing  that  this  function  shall  do  is  Inspect  the  sta¬ 
tus  of  the  task  that  requested  the  services.  If  the  task  was  operating  as  a 
"Privileged  Mode"  Task,  the  local  executive  shall  return  immediate  control 
to  the  task,  rather  than  perform  the  checking  mentioned  above  and  servicing 
the  pending  requests. 

3. 2. 1.3. 3  Outputs  from  Application  Software  Interface  Control  Functions 

The  outputs  received  from  this  control  function  are  listed  in 

Table  VI. 

The  Walt  chain  listed  in  this  table  is  a  result  of  the  Walt 
function.  It  is  a  chain  of  tasks  waiting  for  the  same  type  of  condition. 
There  shall  be  one  Walt  chain  for  tasks  waiting  on  time,  one  for  each  event 
waited  on,  and  one  for  each  event  whose  complement  is  waited  on. 

All  tasks  in  same  Wait  chains  are  tied  together  by  the  forward 
and  back  pointers  in  their  Local  Processor  Tasks  Table  B  entries  (ref.  Par. 

3. 2. 1.5.1).  The  Wait  chain  on  time  is  ordered  by  time.  The  first  task  In 
a  chain  waiting  on  an  event  or  the  complement  of  an  event  is  located  by  a 
pointer  in  the  Event  Record  Table  entry  for  the  event  (ref.  Table  VII  ). 
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3. 2. 1.4  Function  Four 

The  Event  Handling  Function  is  exercised  from  requests  by 
tasks  in  the  local  processor  or,  through  transmitted  messages,  from  tasks 
related  to  a  remote  processor  or  remote  terminals. 

i 

All  the  information  concerning  events  is  kept  in  an  Event 
Record  Table.  Each  processor  contains  an  event  record  for  each  Event  con¬ 
tained  within  the  processor.  The  Event  Handling  Function  shall  act  on 
Event  Condition  Sets  as  specified  in  the  Event  Record  Table.  This  Event 
Record  Table  is  Illustrated  in  Table  VII. 

3. 2. 1.4.1  Inputs  to  Event  Handling  Function 

The  inputs  to  this  function  are  shown  in  Table  VIII. 

3. 2. 1.4. 2  Event  Handling  Processing 

The  IDAMST  Executive  System  receives  requests  for  event  pro¬ 
cessing  from  application  software  tasks  or  executive  tasks.  These  requests 
will  consist  of  commands  to  set  an  Event  to  a  value  of  "1"  or  "0".  The  pro¬ 
cessing  of  this  function  is  accomplished  as  demonstrated  in  Figure  21. 

The  processing  of  this  function  consists  of  setting  the  desired  value  of  an 
Event  Into  the  Event  Record  Table.  If  the  table  indicates  that  there  are 
copies  of  this  event  In  other  processors,  an  asynchronous  message  Is  formu¬ 
lated  and  enqueued. 

The  Event  Record  Table  indicates  any  local  tasks  with  the 
Event  as  part  of  their  Event  Condition  Set.  Thus,  these  conditions  are  set 
In  the  respective  Task  Table  B  entries. 

Finally,  the  Task  Checking  Function  Is  invoked  to  check  the 
condition  status  of  these  tasks. 

3. 2. 1.4. 3  Outputs  from  the  Event  Handling  Function 
Outputs  from  this  function  are  shown  in  Table  IX. 
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FIG.  21  EVENT  HANDLING  PROCESSING 
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3. 2. 1.5  Function  Five  -  Task  Checking  -  Local  Executive 

The  purpose  of  this  function  Is  to  determine  whether  a  given 
task  should  change  states  and  become  Active. 

3. 2. 1.5.1  Inputs  to  the  Task  Checking  Function 

Related  to  each  task  resident  In  a  processor  there  exists  a 
table  Internal  to  the  Local  Processor.  The  entries  to  this  table,  described 
in  Table  X  are  ordered  according  to  the  tasks  priority. 

The  Inputs  to  the  Task  Checking  Functions  shall  be,  as  listed 
in  Table  XI,  the  entries  to  the  tasks  on  the  Local  Processor  Tasks 

Table  B. 

3. 2. 1.5. 2  Task  Checking  Function  Processing 

This  function  will  be  invoked  by  the  Local  Executive  Control: 

a)  Each  time  a  task  Is  Invoked. 

b)  Each  time  an  Event,  except  Minor  Cycle  Events,  Is  signalled 
and  posted  In  the  Local  Processor  Tasks  Table  B  (ref.  Table 

X). 

c)  Whenever  a  Task  ends. 

d)  Whenever  a  Task  is  forcibly  terminated. 

This  function  is  processed  as  indicated  In  Figure  22. 

As  this  function  Is  invoked,  It  will  verify  the  status  of  the  Task  from  the 
Local  Processor  Tasks  Table.  A  task  can  be  In  either  of  two  states,  invoked 
or  uninvoked,  as  shown  In  Figure  6  and  explained  in  Section  3. 2. 2. 2 

If  In  an  Invoked  state,  the  Task  Event  Condition  Set  is  checked  against  the 
desired  Event  Condition  Set  as  established  In  the  input  table.  If  all  condi¬ 
tions  are  satisfied,  the  Task  state  Is  changed  to  Active  and  Dlspatchable  and 
all  Its  Unlatched  Events  Conditions  are  complemented.  If  the  task  Is  Indi¬ 
cated  as  a  Privileged  Mode  task.  It  will  be  called  Immediately  and  control 
is  transferred  to  the  task.  Either  way,  If  the  task  has  an  Activation/Termi¬ 
nation  Event,  the  Event  Is  put  into  the  Event  queue. 

3. 2. 1.5. 3  Output  from  Task  Checking  Function 

The  outputs  from  this  function  are  listed  In  Table  XII. 
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TABLE  X  LOCAL  PROCESSOR  TASKS  TABLE  B 


Save  Area  for  Regs,  and  P.C.  Program  Counter  &  Regs,  will  be  saved  during  an 

Interrupt  or  Walt  Function 


TABLE  XI  INPUTS  TO  TASK  CHECKING  FUNCTION 


3. 2. 1.6 


Function  Six  -  Task  Dispatching  -  Local  Executive 
The  main  purpose  of  the  Task  Dispatching  Function  Is  to  search 
for  the  highest  priority  dlspatchable  task  in  the  Processor.  Upon  finding 
a  task,  control  Is  transferred  to  It. 

» 

3. 2. 1.6.1  Inputs  to  Task  Dispatching  Function 

The  inputs  to  this  function  are  listed  in  Table  XIII. 

3. 2. 1.6. 2  Task  Dispatching  Processing 

The  Task  Dispatching  Function  is  called  by  the  Local  Executive 
Control  Function.  It  takes  place  whenever  the  Event  Queue  is  empty,  the 
Task  Checking  Function  and  all  other  Local  Executive  Tasks  have  been  com¬ 
pleted. 


The  objective  Is  to  determine  the  highest  priority  task  In  the 
local  processor  that  is  In  the  dlspatchable  state.  If  the  task  Is  being 
resumed  from  an  interrupt  point,  the  save  area  will  contain  the  address  at 
where  the  task  was  Interrupted  and  the  information  contained  in  all  the  reg¬ 
isters  at  the  time  of  interruption.  If  the  task  is  being  entered  at  Its 
beginning,  only  the  task  start  address  will  be  defined;  therefore  when 
Initiated,  tasks  cannot  depend  upon  register  initialization. 

The  Local  Executive  Control  Function,  through  the  Task  Check¬ 
ing  Function,  keeps  track  of  the  highest  priority  task  made  dlspatchable 
since  the  last  Dispatch.  Thus,  when  the  Task  Dispatching  Function  is  called. 
It  commences  scanning  on  the  task  table  starting  with  the  highest  priority 
Dlspatchable  task.  If  the  last  Dispatched  task  is  still  the  Highest  Prior¬ 
ity  Task,  then  control  will  be  returned  to  the  original  task.  Otherwise, 
control  will  be  given  to  a  new  task. 

Upon  normal  termination,  the  dispatched  task  returns  to  the 
Task  Dispatching  Function.  The  dispatcher  will.  In  turn,  return  to  the 
Local  Executive  Control  Function. 


The  processing  accomplished  by  this  Function  is  illustrated 

in  Figure  23. 

3. 2. 1.6. 3  Outputs  from  Task  Dispatching  Function 

The  outputs  from  this  Function  are  listed  in  Table  XIV. 

3. 2. 1.7  Function  Seven  -  Minor  Cycle  Set-Up  Function 

The  Minor  Cycle  Set-Up  Function  shall  be  Initiated  by  the 
Local  Executive  Control  Function  upon  detection  of  a  pending  Minor  Cycle. 

This  function  performs  the  processing  necessary  to  prepare  for  synchronous 
message  transmission  and  reception  each  minor  cycle. 

3. 2. 1.7.1  Inputs  to  the  Minor  Cycle  Set-Up  Function 

The  Inputs  to  this  function  are  listed  in  Table  XV 
and  described  in  the  following  paragraphs. 

The  Synchronous  I/O  Tables  are  used  to  determine  which  DMA 
Pointers  to  set  up  In  the  appropriate  DMA  Pointer  Block  on  any  given  Minor 
Cycle. 

a)  Synchronous  Pointer  Table  (SYNPTR) 

The  SYNPTR  Table  will  appear  once  in  every  processor  that  has 
any  dynamically  maintained  synchronous  pointers  in  the  DMA  Pointer  Block 
(ref.  para.  3. 2. 1.7. 3).  It  contains  two  blocks  of  pointers  for  each  Minor 
Cycle.  One  contains  the  addresses  of  all  Compool  blocks  received  during  the 
Minor  Cycle,  excluding  the  Compool  blocks  whose  addresses  are  fixed  within 
the  appropriate  DMA  Pointer  Block.  The  other  contains  the  addresses  of  all 
Compool  blocks  transmitted  during  the  Minor  Cycle  but  not  fixed  within  the 
appropriate  DMA  Pointer  Block.  If  for  a  given  Minor  Cycle,  all  the  DMA  Poin¬ 
ters  within  the  DMA  Pointer  Block  are  of  a  fixed  nature,  then  the  appropriate 
pointer  in  SYNPTR  for  this  Minor  Cycle  shall  be  null. 
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/ask  dispatching 

(R$OM  LOCAL  EXEpl  CONTROL) 


Table  XIV  OUTPUTS  FROM  TASK  DISPATCHING  FUNCTION 


b)  SYNPTR  Index  Table 

The  SYNPTR  Index  Table  Is  used  to  locate  the  blocks  of  Receive 
and  Transmit  Pointers  within  SYNPTR  for  any  Minor  Cycle.  This  table  shall 
appear  once  In  every  processor  that  has  dynamically  maintained  pointers  In 
the  DMA  Pointer  Block  and  will  contain  one  entry  for  every  minor  cycle  num¬ 
ber.  The  Items  In  this  table  are  described  In  Table  XVI  below. 

TABLE  XVI  SYNCHRONOUS  POINTER  INDEX  TABLE 


ITEM 

NO. 

DESCRIPTION 

1 

Number  of  variable  Synchronous  Receive  Pointers 
for  this  Minor  Cycle  within  SYNPTR. 

2 

Offset  from  the  beginning  SYNPTR  to  first  Receive 

Pointer  in  SYNPTR  for  this  Minor  Cycle. 

3 

Number  of  variable  Synchronous  Transmit  Pointers 
for  this  Minor  Cycle  within  SYNPTR. 

4 

Offset  Its  first  Transmit  Pointer  in  SYNPTR 

_ 

for  this  Minor  Cycle. 

c)  Pointer  Block  Descriptor 

The  Pointer  Block  Descriptor  shall  appear  once  In  every  pro¬ 
cessor.  It  Is  used  by  the  Minor  Cycle  Set-Up  Function  to  determine  which 
parts  of  the  DMA  Pointer  Blocks  are  fixed  and  which  are  variable. 

It  contains  four  words  as  shown  In  Table  XVII.  They  are 
pointers  to  the  first  nonflxed  pointer  In  the  respective  block  of  the  OHA 
Pointer  Block. 
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TABLE  XVII 


POINTER  BLOCK  DESCRIPTOR  TABLE 


ITEM 

NO. 

DESCRIPTION 

1 

Address  of  first  variable  Receive  Pointer  In  Block  0 

2 

Address  of  first  variable  Transmit  Pointer  In  Bio' \  0 

3 

Address  of  first  variable  Receive  Pointer  In  Block  1 

4 

Address  of  first  variable  Transmit  Pointer  In  Block  1 

Minor  Cycle  Event  Generation  Table 

The  Minor  Cycle  Event  Generation  Table  shall  appear  once  In 

every  processor  in  the  IDAMST  system.  This  table  shall  be  used  by  the  Local 
Executive  to  determine  which  Minor  Cycle  Event  to  signal  on  any  given  Minor 
Cycle. 


The  Minor-Cycle  Event  Generation  Table  consists  of  two  Inter¬ 
dependent  parts.  The  first  part  shall  contain  an  entry  for  every  Minor  Cycle 
in  a  major  frame  ordered  by  Minor  Cycle  number.  Minor  Cycles  shall  be  num¬ 
bered  in  ascending  order.  Each  entry  shall  contain  two  Items.  One  entry 
shall  indicate  the  number  of  Events  for  the  Minor  Cycle.  The  second  entry  is 
an  Index  field  containing  an  offset  to  the  beginning  of  the  second  part  of 
the  table.  This  offset  points  to  the  beginning  of  a  list  of  Event  Table 
pointers  which  point  to  the  appropriate  period  -  phase  events  In  the  Event 
Record  Table  (Table  VII  ).  If  there  are  no  Minor  Cycle  events  for  a 
given  Minor  Cycle,  the  proper  entries  In  the  first  part  of  the  table  shall  be 
set  to  zero. 
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The  actual  arrangement  of  Event  Record  Table  pointers  may 
vary  within  the  second  part  of  the  Minor-Cycle  Event  Generation  Table.  Many 
distinct  Minor  Cycles  can  cause  activation  of  an  Identical  list  of  Minor 
Cycle  Events,  thus  the  groups  pointed  to  by  Part  1  of  this  table  for  several 
different  Minor  Cycles  may  be  the  same. 
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An  Illustration  of  the  Minor-Cycle  Event  Generation  Table 
Is  shown  In  Table  XVIII. 

TABLE  XVIII  MINOR  CYCLE  EVENT  GENERATION  TABLE 


Number  of  Events 
for  Minor  Cycle  0 

Offset  to  First  Event  for  this  Minor 
Cycle  in  Part  2 

Number  of  Events  for 
Minor  Cycle  1 

Offset  for  this  Minor  Cycle  In  Part  2 

1 

Number  of  Events 

Last  Minor  Cycle 

Offset  In  Part  2 

Blank 

Offset  into  Event  Record  Table 

Blank 

Offset  into  Event  Record  Table 

3. 2. 1.7.2  Minor  Cycle  Set-Up  Processing 

The  main  objective  of  this  Function  Is  to  generate  the 
address  pointers  used  by  the  Bus  Controller  Interface  Unit  (BCIU)  to  store 
or  access,  via  the  DMA  channel,  synchronous  message  data  received  or  syn¬ 
chronous  message  to  be  transmitted.  These  pointers  shall  be  stored  fn  a 
table  designated  as  DMA  Pointers  Table. 


This  Function  also  determines  which  tasks  depend  on  the 
M1no*-£ycle to  become  dlspatchable.  Those  tasks  that  have  their  Event  Condi¬ 
tion  Set  satTsTTed-by^thls  Minor-Cycle  and  are  "Privileged  Mode"  tasks,  shall 
become  Active,  Dispatchable  and  directly  executable  by  the  Minor-Cycle  Set-Up 
Function.  This  action  takes  advantage  of  its  knowledge  of  the  nature  of  the 
Events  It  Is  signalling  to  bypass  the  Event  Handling  Function  (3.2. 1.4)  and 
the  Task  Checking  Function  (3. 2. 1.5)  of  the  Local  Executive. 

The  processing  performed  by  this  Function  Is  Illustrated  In 

Figure  24. 


In  the  process  of  setting  up  the  DMA  Pointer  Table,  this 
Function  makes  use  of  the  Minor  Cycle  number  to  Index  Into  the  SYNPTR  Index 
Table.  With  the  Information  obtained  from  this  table,  the  SYNPTR  for  the 
particular  Minor  Cycle  will  be  read  and  the  addresses  of  all  Compool  blocks 
to  be  received  and  transmitted  during  the  Minor  Cycle  will  be  fetched.  Mak¬ 
ing  use  of  the  information  stored  In  the  Pointer  Block  Descriptor  Table,  the 
Compool  blocks  addresses  shall  be  stored  In  the  DMA  Pointer  Tables.  The  DMA 
Pointer  Tables  are  described  In  Paragraph  3. 2. 1.7. 3.. 

3. 2. 1.7. 3  Outputs  from  the  Minor  Cycle  Set-Up  Function 

The  Items  output  from  this  Function  are  summarized  In 

Table  XIX. 

The  DMA  Pointers  Blocks  Table  shall  contain  the  address 
pointers  for  the  Compool  blocks  Into  which  receive  messages  are  to  be  stored 
by  the  BCIU  and  out  of  which  the  BCIU  will  access  messages  for  transmission 
during  a  Minor  Cycle.  This  table,  as  shown  In  Table  XVI  Is  divided 
Into  four  parts.  Two  parts  are  used  for  even-numbered  Minor  Cycles  and  the 
other  two  for  odd-numbered  Minor  Cycles. 

Part  1  shall  contain  pointers  for  message  reception  while 
Part  2  shall  contain  pointers  for  message  transmission.  Each  part  shall  con¬ 
tain  up  to  31  pointers  that  are  accessed  by  the  BCIU  as  described  In  Section 
3.2.1. 2.  Word  0  In  each  block  shall  not  be  used  as  a  pointer  since  a  sub- 
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FIGURE  24. 


PROCESSING  OF  MINOR  CYCLE  SET-UP  FUNCTION 


TABLE  XIX  OUTPUTS  FROM  MINOR  CYCLE  SET-UP  FUNCTION 


address  of  zero  Indicates  a  Mode  operation.  The  pointer  corresponding  to  sub 
address  31,  for  both  reception  and  transmission,  Is  reserved  for  asychronous 
message  reception  and  transmission. 


The  table  shall  contain  fixed  pointers  and  some  that  are 
dynamically  set  up  every  time  the  DMA  Pointer  Block  is  used.  Thus,  if  a  corn- 
pool  Is  received  or  transmitted  every  even  or  every  odd  minor  cycle,  then  its 
pointer  shall  remain  fixed  In  the  DMA  Pointer  Block. 

3. 2. 1.8  Function  Eight  -  Asynchronous  Message  Handling  Function 

The  Asynchronous  Message  Handling  Function  shall  manage 
the  reception  and  transmission  of  asynchronous  messages  via  the  BCIU.  Asyn¬ 
chronous  messages  are  utilized  to  perform  the  following: 


a.  Invoke  a  task  when  a  task  is  located  in  a  different 
processor  than  Its  controller. 

b.  Task  terminatlon/cancellation  when  a  task  to  be  termina¬ 
ted  or  cancelled  is  in  a  different  processor  than  the  controller  task. 

c.  Write  compool  block  data  when  the  compool  block  to  be 
written  has  copies  In  other  processors. 

d.  Signal  Events  when  the  Event  Record  has  copies  in  other 


processors. 

Terminals. 


e.  Update  Compool  Blocks  in  other  processors  or  Remote 


I 


a 


Although  the  Local  Executive  determines  the  necessity  for 
an  asynchronous  message  transmission,  the  actual  transmission  of  the  message 
Is  controlled  by  the  Master  Executive  located  in  the  Master  Processor. 

3. 2. 1.8.1  Asynchronous  Message  Reception  Function 

The  Asynchronous  Message  Reception  Function  shall  accept 
an  Incoming  Asynchronous  message  received  through  the  BCIU  and  enqueue  It  Is 
processing. 


3. 2. 1.8. 1.1  Inputs  to  Asynchronous  Message  Reception  Function 

The  Input  to  this  function  shall  be  the  Reception  Queue  as 

noted  In  Table  XX. 
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The  Reception  Queue,  as  illustrated  In  Figure  25 
shall  consist  of  the  following  Items: 

a.  The  Request  Pending  Flag  Indicating  the  presence  of  a 
message  that  has  not  been  processed  by  the  Local  Executive. 

b.  Three  33-words  buffers  for  storing  the  received 
Asynchronous  messages. 

c.  Pointer  to  first  buffer  in  queue  indicating  the  next 
buffer  to  be  processed,  i.e.,  the  buffer  succeeding  the  last  one  fully  pro¬ 
cessed. 

d.  Pointer  to  last  buffer  in  queue  pointing  to  the  last 
buffer  filled  by  a  reception  from  the  BCIU. 

The  Reception  Queue  is  filled  in  by  the  BCIU.  (Section 
3. 2. 1.2)  and  removed  from  it  by  the  Local  Executive  Control  Function  (Section 

3. 2. 1.1)  in  a  First-In-First-Out  basis. 

The  reception  buffers  are  considered  to  be  arranged  cycli¬ 
cally,  thus,  the  last  physical  buffer  succeeds  the  first  physical  buffer. 

3. 2. 1.8. 1.2  Asynchronous  Message  Reception  Processing 

The  Asynchronous  Message  Reception  Function  Is  Invoked  by 
the  Hardware  Interface  Control  Function  after  receiving  a  level  of  interrupt 
indicating  the  reception  of  an  asynchronous  message. 

The  Asynchronous  Reception  Function  shall  examine  the  Asyn¬ 
chronous  Message  ID.  If  the  ID  indicates  a  realignment  request,  the  Asyn¬ 
chronous  Transmission  Function  shall  be  called  to  re-transmlt  the  last  mes¬ 
sage.  Otherwise,  as  indicated  in  Figure  26  ,  the  "Next  Buffer"  and 

"Last  Buffer"  pointers  in  the  Reception  Queue  are  adjusted  (ref.  para. 

3. 2.1. 8.1.1)  and  the  "Reception  Pending"  Flag  in  the  same  queue  is  set. 
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The  "BUSY"  bit  In  the  BCIU  PCR  register  shall  be  set  to 
zero  only  If  the  Reception  Queue  Is  not  full  with  unprocessed  messages. 

3. 2. 1.8.1. 3  Outputs  from  Asynchronous  Message  Reception  Function 

The  outputs  from  the  Asynchronous  Message  Reception  Func¬ 
tion  are  listed  In  Table  XXI. 

3. 2. 1.8. 2  Asynchronous  Message  Transmission  Function 

The  Asynchronous  Transmission  Function  accepts  messages 
enqueued  by  the  Local  Executive  Into  a  transmission  queue  and  prepares  them 
for  transmission  by  the  BCIU.  The  necessity  for  the  transmission  of  an  asyn¬ 
chronous  message  Is  determined  by  the  Local  Executive  In  order  to  accomplish 
tasks  services  as  enumerated  In  paragraph  3. 2. 1.8. 

This  function  is  invoked  from: 

a)  The  Interrupt  Handling  Function  (Section  3. 2. 1.2)  after 
termination  of  a  previous  Asynchronous  transmission. 

b)  The  Asynchronous  Message  Reception  Function  (Section 
3. 2. 1.8.1)  upon  reception  of  a  message  requesting  a  retransmission  of  the 
last  message. 

c)  The  Local  Executive  Control  Function  on  a  request  to 
Initiate  a  BCIU  transmission. 

3. 2. 1.8. 2.1  Inputs  to  Asynchronous  Message  Transmission  Function 

The  input  to  this  function  is  a  Transmission  Queue  as  noted 

In  Table  XXII. 


The  Transmission  Queue  Is  Illustrated  In  Figure  27. 

It  consists  of  a  number  of  Message  Descriptor  Blocks  that  contain  pertinent 
message  Information  and  a  series  of  pointers  used  In  the  fetching  of  the  mes¬ 
sages  to  be  transmitted.  A  description  of  these  parameters  follows: 
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OUTPUTS  FROM  ASYNCHRONOUS  MESSAGE  RECEPTION  FUNCTION 


ASYNCHRONOUS  MESSAGE  TRANSMISSION  FUNCTION 


Message  Descriptor  Blocks 


Final 

Transm?” 

Pointer 


Last  __ 

Transm. 

Pointer 

Current 

Transm.” 

Pointer 


Request  Vector  #4 
Async  ID  #4 
Buffer  Pointer  #4 


Request  Vector  #5 
Async  ID  #5 
Buffer  Pointer  #5 


Available  for  enqueuing 
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Request  Vector  #0 
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FIGURE  27 


TRANSMISSION  QUEUE 


The  Message  Descriptor  Block  consists  of: 


1.  Asynchronous  Request  Vector 

The  Asynchronous  Request  Vector  Is  a  9-blt  cpde  that 
Identifies  each  asynchronous  message  that  exists  In  the  system.  If  the  local 
executive  Is  not  In  the  Master  Processor,  an  Asynchronous  Request  Vector  asso¬ 
ciated  with  an  Asynchronous  message  to  be  transmitted  will  be  loaded  Into  the 
BCIU  Status  Code  Register  (SCR).  This  Status  Code  Register  will  be  decoded 
by  the  Master  Processor  and  as  a  consequence  the  Master  Processor  will  gener¬ 
ate  the  commands  required  by  the  asynchronous  messages  as  described  In  para¬ 
graph  3. 3. 2. 3. 


If  the  local  executive  Is  located  In  the  Master  Proces¬ 
sor,  this  Request  Vector  will  be  input  to  the  Master  Asynchronous  Control 
Function  through  Its  vector  stack  (ref.  para.  3. 2. 2. 3). 

2.  Asynchronous  ID  Word 

The  ID  word  will  be  appended  to  the  beginning  of  the 
message  and  the  Local  Executive  receiving  the  message  will  make  use  of  this 
word  In  identifying  the  message,  (ref.  para.  3. 2. 1.1. 2).  The  Asynchronous 
ID  word  will  contain  the  address  offset  to  the  message  Data  Descriptor  Block 
(DDB)  (ref.  3. 2. 1.3)  If  a  Compool  Block  Handling  Is  Invoked.  If  the  message 
Is  to  be  sent  to  an  RT,  the  ID  shall  be  set  equal  to  177777,  and  shall  not  be 
appended  to  the  message. 

3.  Pointer  Into  Transmission  Buffer  Area 

The  buffer  pointer  points  to  a  buffer  allocated  within  the 
transmission  buffer  area  holding  the  data  to  be  transmitted.  It  should  be 
noted  that  the  first  two  words  of  each  buffer  shall  contain  a  Tag  Word  as 
described  In  3. 2. 1.2,  and  the  Asynchronous  ID  word,  respectively.  The  data 
begins  on  the  third  word.  If  a  message  has  no  associated  data,  the  buffer 
pointer  Is  zero  and  no  buffer  Is  allocated  for  the  message.  On  the  other 
hand.  It  Is  possible  for  a  series  of  messages  to  point  to  the  same  buffer. 


b)  Last  Transmission  Pointer  (LTP)  pointing  to  the  Message 
Descriptor  Block  of  the  last  message  transmitted  by  the  BCIU. 

c)  Current  Transmission  Pointer  (CTP)  pointing  to  the  Mes¬ 
sage  Descriptor  Block  as  the  message  currently  set-up  for  transmission  by  the 
BCIU. 

d)  Final  Transmission  Pointer  (FTP)  pointing  to  the  Message 
Descriptor  Block  of  the  message  most  recently  enqueued  by  the  Local  Executive. 

e)  Transmission  Buffer  Area  used  to  hold  the  data  to  be 

transmitted. 


f)  First  Used  Buffer  Pointer  (FUBP)  pointing  to  the  first 
word  In  the  area  occupied  by  a  message,  thus  unavailable  for  enqueuelng  mes¬ 
sages. 

g)  First  Free  Buffer  Pointer  (FFBP)  pointing  to  the  first 
word  In  the  buffer  area  available  for  storing  new  transmission  messages. 


3. 2. 1.8. 2. 2  Asynchronous  Message  Transmission  Processing 

The  Asynchronous  Transmission  Function  shall  dispose  of 
messages  stored  In  Its  transmission  queue  In  a  First- In-First-Out  basis.  To 
this  effect  It  shall  make  use  of  the  transmission  pointers  identified  in  the 
Transmission  Queue  as  described  in  Para.  3. 2. 1.8. 2.1. 


Upon  being  entered,  the  Asynchronous  Message  Transmission 
Function  shall  have  Its  Current  Transmission  Pointer  (CTP)  pointing  at  the 
Description  Block  of  the  message  last  transmitted.  Thus,  upon  a  request  to 
retransmit  the  previous  message,  CTP  will  be  equal  to  the  Last  Transmission 
Pointer  (LTP). 


Figure  28  illustrates  this  function  processing. 

3.2. 1.8.2. 3  Outputs  from  Asynchronous  Message  Transmission  Function 
The  outputs  from  this  function  are  listed  In  Table  XXIII. 
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FIGURE  28.  ASYNCH.  MSG  TRANSM.  PROCESSING 


ASYNCHRONOUS  MESSAGE  TRANSMISSION  FUNCTION 


3. 2. 1.9  Function  Nine  -  Local  Executive  Initialization  Function 

This  function  Is  Invoked  by  the  system  hardware,  namely,  the 
ROM,  upon  system  Initialization  on  request  from  the  pilot  or  on  reinitiali¬ 
zation  as  a  recovery  from  a  power-down  condition. 

i 

Its  purpose  Is  to  Initialize  or  reinitialize  the  state  of 
the  Local  Executive  and  the  BCIU  associated  with  the  Remote  Processor. 

3. 2. 1.9.1  Inputs  to  the  Local  Executive  Initialization  Function 
The  Inputs  to  this  function  shall  be  as  listed  In  Table 
XXIV. 

3. 2. 1.9. 2  Processing  of  Local  Executive  Initialization  Function 
The  pilot  shall  manually  power-up  the  system  and  turn  the 

"processors  on."  The  pilot  shall  have  the  capability  to  restart  the  system 
and  thus  initialize  a  start-up  sequence. 

Each  processor  initiates  operation  under  control  of  the 
start-up  program  residing  In  its  ROM.  This  start-up  program  shall  determine 
whether  a  normal  start-up  or  a  power-transient  recovery  is  to  be  initiated. 

For  a  normal  start-up,  the  ROM  shall  perform  a  processor 
self- test  and  Initiate  the  BCIU  self- test. 

The  Processor  Control  Panel  (PCP)  discretes  shall  be  read 
and  the  processor  assignment  determined.  The  BCIU  shall  be  Initialized  by 
loading  the  BCIU  address  into  the  PCR  bits  7-11,  setting  the  Master/Remote 
(bit  1)  bit  In  the  PCR  to  agree  with  the  processor's  assignment  and  setting 
the  Go  bit  (bit  2)  of  the  PCR  to  1. 

After  the  software  has  been  loaded  from  mass  memory  the 
local  processor  executive  system  tables  are  Initialized  and  set  up  for  a 
minor  cycle  0. 

The  Local  Exec  Initialization  Processing  Sequence  is 
shown  In  Figure  29. 
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FIGURE  29.  LOCAL  EXEC.  INITIALIZATION  PROCESSING 


If  a  remote  or  monitor  processor  recovers  from  a  successful 
power- transient,  an  Event  shall  be  signalled  to  start  the  power- recovery 
operations. 


If  the  local  executive  determines  that  Its  BCIU  Is  not 
operating  (PCR  "Ready"  bit  1),  It  shall  Initialize  the  BCIU  and  through  the 
POP  discretes  determine  the  processor  assignment.  The  local  executive  shall 
Initialize  for  power- transient  recovery  by  signalling  the  Master  Processor 
about  the  power  recovery  through  the  BCIU  bit  register  and  setting  the  BCIU 
synchronous  compool  pointers  to  "null"  compools.  The  master  processor, 
upon  receiving  indication  of  a  transient  recovery,  shall  restart  operation 
at  the  end  of  the  last  successful  minor  cycle.  Finally,  the  BCIU  PCR  shall 
be  set  to  •Go". 


3.2. 1.9. 3 


Outputs  from  the  Local  Executive  Initialization  Function 
The  outputs  from  this  function  are  listed  In  Table  XXV. 
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3.2.2  IDAMST  Master  Executive  Functions 

The  Master  Executive  shall  reside  In  the  master  processor 
and  In  the  monitor  processor.  Its  main  function  Is  to  manage  and  control 
all  data  bus  communication  among  the  processors  and  remote  terminals  and 
direct  the  Initialization  and  start-up  on  the  software  system. 

A  block  diagram  of  Its  functions  Is  shown  In  Figure  30. 


3. 2. 2.1  Function  Ten  -  Master  Executive  Initialization  &  Start-Up 
Functions" 

The  main  objective  of  this  function  Is  to  establish  the 
proper  operational  sequence  to  enter  normal  system  operations. 

Each  processor  In  the  IDAMST  system  will  contain  a  basic 
start-up  program  residing  In  a  READ-Only-Memory  (ROM)  module  which  will  con¬ 
trol  the  Initiation  of  operations  within  the  processors. 

This  start-up  program  sequence  Is  considered  part  of  the 
initialization  function  and  as  such  is  being  described  in  the  processing 
description  of  this  function  (ref.  para.  3. 2.2. 1.2). 

3. 2. 2. 1.1  Inputs  to  Master  Executive  Initialization  &  Start-Up 
The  Inputs  to  this  function  are  listed  In  Table  XXVI. 

3. 2. 2. 1.2  Initialization  &  Start-Up  Processing 

This  function  processing  is  Illustrated  In  Figure  31 

and  Figure  32. 

The  start-up  procedure  shall  be  Initiated  by  the  pilot  going 
through  a  sequence  of  actions  using  the  Processor  Control  Panel  (PCP).  These 
are: 


a)  Manually  turning  the  power-on  for  the  system.  This  action 
shall  set  a  "normal  start-up"  discrete. 
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FIGURE  31.  MASTER  EXECUTIVE  INITIALIZATION 


FIGURE  32.  MASTER  EXECUTIVE  START-UP 
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b)  Turning  the  power-on  for  every  processor. 

c)  Activating  a  "START"  switch  to  Initiate  system  start-up. 

Upon  the  start-up  program  In  the  ROM  taking  control,  it  shall 
check  for  a  normal  start-up  sequence  ("normal  start-up"  discrete).  If  this 
discrete  has  not  been  set,  the  program  will  determine  If  a  successful  power 
shut  down  was  accomplished.  If  successful,  the  master  executive  shall  sig¬ 
nal  the  other  processors  of  the  necessary  operation  and  Initiate  minor 
cycle  operation  at  the  end  of  the  last  successful  minor  cycle.  The  Local 
Executive  shall  execute  Its  sequence  as  described  in  Function  Nine,  para¬ 
graph  3. 2. 1.9.  If  the  power  shut-down  was  not  accomplished  successfully,  a 
normal  start-up  sequence  shall  be  performed. 

The  ROM  start-up  program  shall  perform  the  processor  and  BCIU 
self- tests,  the  processor/BCIU  Interface  test  and  read  the  PCP  assignment 
discretes  to  Initialize  the  BCIU  as  per  Its  Master/Remote  bit  and  the  device 
address  and  setting  the  PCR  "60"  bit.  If  the  tests  are  satisfactory  the 
Master  Executive  shall  be  loaded  from  mass  memory  and  a  check  sum  performed 
on  the  master  executive. 

The  master  executive  will  take  control  and  perform  a  bus 
communication  test  with  the  other  processors. 

If  a  failure  occurs  in  any  of  the  previous  tests,  l.e.  pro¬ 
cessor  self- test,  BCIU  self- test,  processor/BCIU  Interface  test,  Master  load 
verification.  Master  load  check  sum,  Remote/Master  bus  conmunl cation  test, 
the  "Fall"  Light"  for  the  respective  processor  shall  be  displayed.  The  pilot 
shall  reassign  the  processors,  turn-off  those  that  failed  and  restart  the 
system. 


After  successful  testing,  the  master  executive  shall  deter¬ 
mine,  from  a  discrete  originating  In  the  Processor  Control  Panel  (PCP)  which 

application  software  to  load  and  the  desired  configuration.  If  the  discrete 
Indicates  GTP-1,  the  GTP-1  software  shall  be  loaded  and  verified  from  mass 
memory.  A  check  sum  shall  also  be  performed  on  each  processor  load. 
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Upon  finishing  the  execution  of  GTP-1,  GTP-2  may  be  Indicated 
through  the  PCP  or  else  regular  mission  software  Is  to  be  loaded  from  mass 
memory.  If  there  has  not  been  a  failure  to  load  the  mission  software,  the 
system  parameters  and  mission-dependent  data  shall  be  loaded  from  mass  mem¬ 
ory. 


To  Initiate  the  normal  system  operation  the  minor  cycle  Inter¬ 
val  timer  shall  be  Initiated  and  the  application  software  master  sequencer 
Invoked. 

3. 2. 2. 1.3  Outputs  from  M.E.  Initialization  &  Start-Up  Function 

Upon  exiting  this  function  the  IDAMST  system  shall  have  each 
processor  loaded  with  the  proper  executive  and  application  software.  One 
processor  shall  contain  master  and  local  executives,  another  processor  shall 
contain  only  a  local  executive  and  the  third  processor  shall  contain  a  master 
executive  with  monitoring  functions  and  a  local  executive.  The  application 
software  shall  be  allocated  as  per  the  configuration  management. 
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3. 2. 2. 2  Function  Eleven  -  Master  Synchronous  Bus  Communication  Control 

The  master  executive  controls  the  transmission  of  synchronous 
message  data  over  the  BCIU  each  minor  cycle.  These  data  may  be  In  the  form 
of  minor  cycle  mode  commands,  actual  synchronous  messages  and/or  status  word 
polling  messages. 

There  are  sixty-four  minor  cycles  occurring  per  major  cycle 
where  a  major  cycle  is  defined  as  occurring  every  second.  Synchronous  mes¬ 
sages  can  be  transmitted  at  different  binary  rates  per  major  cycle,  thus,  the 
possible  synchronous  data  periods  are: 

1  Every  Cycle 

2  Every  Other  Cycle 

4  Every  Four  Cycles 

8  Every  Eight  Cycles 

16  Four  Times  a  Major  Cycle 
32  Twice  a  Major  Cycle 
64  Once  a  Major  Cycle 

Synchronous  messages,  while  perhaps  on  the  same  period  as 
described  above,  can  be  scheduled  on  the  BCIU  at  different  phases  with 
respect  to  the  start  of  the  major  cycle.  Thus  every  message  has  associated 
with  it  a  period  and  a  phase.  The  phase  of  a  message  is  its  displacement 
relative  to  the  first  minor  cycle.  A  message  with  a  period  of  two  will  have 
its  first  occurrence  In  minor  cycle  0  or  1  with  a  phase  of  0  or  1  accordingly 
similarly  for  a  period  of  four  the  message  can  have  a  phase  of  0,  1,  2,  or  3. 
Messages  transmitted  each  minor  cycle  always  have  a  phase  of  0  and  a  period 
of  1. 


A  phase  table,  as  Illustrated  In  Figure  34  ,  Identifies 
the  phases  associated  with  the  minor  cycles  with  respect  to  the  transmission 
rates. 
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3. 2. 2. 2.1  Inputs  to  Waster  Synchronous  Control  Function 

The  inputs  to  this  function  are  listed  in  Table  XXVII. 

The  input  tables  are  described  below. 

3. 2. 2. 2. 1.1  BCIU  Instruction  Formats 

Each  BCIU  command  consists  of  instruction  pairs  in  the  format 
as  Illustrated  in  Figure  33.  The  BCIU  sequentially  interpret  each 

instruction  pair  to  determine  the  action  required.  Depending  on  the  OP  Code 
contained  In  the  Instruction  pair,  the  BCIU  will  initiate  a  bus  transmission, 
transmit  a  masking  mode  command,  perform  any  bus  operations  but  will  use  the 
second  word  of  the  instruction  as  the  address  of  the  next  instruction  pair. 
The  rest  of  the  fields  in  the  instruction  pair  are  described  in  detail  in 
Section  3. 1.1.1. 

3. 2. 2. 2. 1.2  BCIU  Synchronous  Instruction  List 

The  BCIU  Instruction  List  contains  an  instruction  pair  for 
each  synchronous  message  that  is  transmitted  on  the  data  bus.  If  any  of  the 
synchronous  transmissions  require  bit  or  word  masking,  the  instruction  pair 
that  affects  the  transmission  will  be  preceded  by  one  to  send  the  proper 
Mode  Command.  A  word  mask  will  also  require  the  loading  of  the  BCIU  Mode 
Data  Register  with  the  desired  word  mask. 

Since  each  message  is  not  transmitted  every  minor  cycle,  the 
instruction  list  must  be  organized  so  that  the  proper  instruction  pairs  can 
be  linked  together  at  the  start  of  each  minor  cycle  to  form  the  complete  In¬ 
struction  list  for  that  minor  cycle.  Thus,  instruction  pairs  are  organized 
in  Instruction  blocks.  The  Synchronous  Instruction  List  will  contain  one 
block  of  Instructions  for  each  phase  and  period  for  which  there  are  synchro¬ 
nous  bus  transmissions.  The  organization  of  these  blocks  is  Illustrated  in 
Figure  34.  The  last  instruction  pair  in  each  Instruction  block  is  a 

Link  instruction.  This  link  Instruction  pair  is  dynamically  set  by  the 
Master  Executive  to  point  to  the  next  block  of  Instructions  to  be  performed 
during  the  current  minor  cycle. 
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TABLE  XXVII  INPUTS  TO  MASTER  SYNCHRONOUS  CONTROL  FUNCTION 


OP  CODES: 


FIGURE  33  BCIU  Instruction  Format 
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3. 2. 2. 2. 1.3 


Instruction  List  Pointer  Table 

This  table  is  used  by  the  Master  Executive  to  set  the  appro¬ 
priate  Link  instruction  pairs  every  minor  cycle.  This  table  Is  Illustrated 
in  Figure  35. 

t 

This  table  will  contain  an  entry  for  each  phase  and  period 
in  which  a  synchronous  message  appears.  The  entries  are  arranged  in  ascend¬ 
ing  sequence  by  phase  and  then  by  period.  Thus,  the  entry  for  phase  X  and 
period  Y  Is  entry  (X  +  Y). 

3. 2. 2. 2. 2  Processing  by  Master  Synchronous  Control  Function 

This  function  is  Initiated  upon  the  occurrence  of  an  interval 
timer  interrupt  and  Its  processing  is  illustrated  in  Figure  36. 

Upon  entering,  this  function  shall  first  determine  whether 

error  processing  is  under  way.  If  this  Is  so  the  error  processing  function 

will  be  Invoked.  Otherwise;  the  function  will  determine  if  all  minor  cycle 
transmissions  have  been  completed.  If  they  are  not  completed,  the  minor 
cycle  shall  be  extended  for  one  more  minor  cycle  period  if  the  minor  cycle 
has  not  been  extended  before.  If  the  minor  cycle  has  been  extended  before, 
a  message  shall  be  displayed  and  the  master  processor  halted.  This  action 
will  cause  the  monitor  processor  to  take  over  and  manage  any  reconfiguration 
request. 


If  the  synchronous  bus  transmissions  for  the  minor  cycle  have 
been  completed,  the  minor  cycle  number  Is  Incremented  and  loaded  into  Master 
Function  Register  of  the  BCIU  and  the  Minor  Cycle  pending  bit  is  set  in  the 
Master  Processor.  A  minor  cycle  phase  table  shall  be  generated  Identifying 
the  phases  applicable  to  all  the  period  for  this  minor  cycle  as  explained  In 
paragraph  3. 2. 2. 2.  Figure  36  Illustrates  this  table  for  three  differ¬ 

ent  minor  cycles. 

Making  use  of  this  table  and  the  Instruction  List  Pointer  Table 
(para.  3. 2. 2. 1.3),  the  appropriate  instruction  blocks  shall  be  linked  creat¬ 
ing  a  continuous  instruction  list  to  control  the  BCIU's  operation  for  the 
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Figure  35  Instruction  List  Pointer  Table 
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FIGURE  37  MASTER  SYNCH.  CONTROL  PROCESSING 


current  minor  cycle. 


The  proper  register  in  the  BCIU  are  loaded  and  the  synchroni¬ 
zation  commands  are  transmitted  to  the  remote  processors. 

t 

3. 2. 2. 2. 3  Outputs  from  Master  Synchronous  Control  Function 

The  outputs  from  this  function  are  shown  in  Table  XXVIII 

3.2.2. 3  Function  Twelve- Asynchronous  Bus  Communication  Control 

The  responsibility  of  this  function  is  to  control  all  asyn¬ 
chronous  communication  through  the  BCIU.  Requests  for  asynchronous  trans¬ 
mission  can  be  received  from  the  local  executive  resident  in  the  remote  pro¬ 
cessor  or  the  local  executive  In  the  master  processor.  Requests  for  trans¬ 
mission  are  Identified  to  the  master  executive  by  the  Interrupt  Request  Vec¬ 
tor  associated  with  each  asynchronous  message. 

The  asynchronous  transmission  is  formulated  as  described  in 
the  following  paragraphs. 

3. 2. 2. 3.1  Inputs  to  Asynchronous  Control  Function 

The  Inputs  to  this  function  are  listed  in  Table  XXIX 

3. 2. 2. 3. 1.1  Request  Vectors 

The  Request  Vectors  are  9-bits  data  fields  associated  with 
the  asynchronous  messages  existing  In  the  system.  Each  request  vector  will 
point  to  a  particular  message,  thus  a  maximum  of  512  asynchronous  messages 
can  be  provided  for  In  the  system. 

A  local  executive  located  In  a  remote  processor  requests  an 
asynchronous  message  by  loading  the  proper  Interrupt  vector  Into  the  BCIU's 
Status  Code  Register.  The  local  executive  located  In  the  Master  Processor 
passes  the  associated  Interrupt  vector  to  the  master  executive  by  loading  It 
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OUTPUTS  FROM  MASTER  SYNCHRONOUS  CONTROL  FUNCTION 


TABLE  XXIX  INPUTS  TO  ASYNCHRONOUS  BUS  COMMUNICATION  CONTROL  FUNCTION 


Into  an  Interrupt  vector  stack.  In  either  case,  the  master  executive  uses 
the  Interrupt  vector  as  an  index  Into  the  Master  Request  Decode  Table  des¬ 
cribed  In  3. 2. 2. 3. 1.2. 

3. 2. 2. 3. 1.2  Master  Request  Decode  Table 

The  Master  Request  Decode  Table  contains  an  entry  for  every 
processor-to-processor  and  processor-to-RT  asynchronous  compool  block  update 
message.  The  Interrupt  vectors  are  used  to  Index  Into  this  table,  thus,  the 
entries  will  be  numbered  in  ascending,  consecutive  order.  Messages  origina¬ 
ting  in  an  RT  are  defined  using  a  different  set  of  tables.  Master  Remote 
Terminal  Request  Tables.  There  are  two  different  types  of  entries  In  this 
table:  one  for  transmissions  Involving  no  masking  and  one  for  transmissions 
Involving  bit  or  word  masking.  For  messages  with  no  masking,  the  entry  is  a 
master  Instruction  set  to  effect  the  transmission.  Messages  that  entail  bit 
or  word  masking  will  have  for  entry  several  items  relating  to  the  mask  des¬ 
cription. 


Item  #1  will  be  zero  to  indicate  that  It  Is  not  a  master 

Instruction  set. 


Item  #2  will  be  a  pointer  to  a  second  table.  Master  Instruc¬ 
tion  Supplement  Table,  describing  the  bit  or  word  masking. 

Item  #3  Is  the  word  mask  that  will  appear  In  the  bus  message. 
If  it  Is  a  bit  masking.  Item  #3  will  be  all  ones. 

3. 2. 2. 3. 1.3  Master  Instruction  Supplement  Table 

This  table  will  contain  an  entry  generated  for  any  asynchron¬ 
ous  message  that  has  word  or  bit  masking  and  originates  at  a  processor. 

Each  entry  contains  two  master  Instruction  sets.  The  first 
Is  the  Mode  command  Indicating  the  proper  masking;  the  second  Is  the  command 
which  performs  the  BCIU  transmission. 
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3. 2. 2. 3. 1.4  Remote  Asynchronous  Table 

If  the  asynchronous  message  received  by  the  Master  Processor 
has  originated  at  a  Remote  Terminal  (RT),  the  Master  Executive  will  make  use 
of  Its  Remote  Terminal  Request  Tables. 

r 

The  Remote  Asynchronous  Table  will  contain  an  entry  for  each 
of  the  32  possible  remote  terminals.  These  entries  will  be  Indexed  by  a 
Remote  Terminal  Identification  number. 

Item  #1  will  contain  the  total  number  of  asynchronous  mes¬ 
sages  transmitted  from  this  RT. 

Item  #2  will  contain  an  index  pointing  to  this  RT's  entry 
In  the  Remote  Terminals  Master  Instruction  Keys  Table. 

3. 2. 2. 3. 1.5  Remote  Terminals  Master  Instruction  Keys  Table 

This  table  will  have  an  entry  for  all  asynchronous  messages 
originated  by  a  Remote  Terminal.  All  the  messages  associated  with  an  RT  will 
be  contiguous  within  the  table. 

The  entries  to  this  table  are  accessed  by  item  #2  of  the 
Remote  Asynchronous  Table  described  In  3. 2. 2. 3. 1.4. 

Item  #1  contains  a  mask  associated  with  the  RT  Activity  Reg¬ 
ister.  This  mask's  value  will  Identify  the  particular  asynchronous  request. 

Item  #2  contains  the  Instruction  Set  necessary  to  satisfy  the 

RT  request. 

3. 2. 2. 3. 2  Asynchronous  Control  Function  Processing 

Asynchronous  Processing  Is  performed  whenever:  (a)  Master 
BCIU  receives  a  status  word  from  a  remote  processor  containing  an  Interrupt 
vector  with  an  octal  value  of  001  through  776.  This  condition  shall  generate 

a  level  3  interrupt  Indicating  the  reception  of  a  valid  status  word. 
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(b)  The  local  executive  located  In  the  Master  Processor  pas¬ 
ses  an  Interrupt  vector  to  the  waster  executive  through  the  Interrupt  vector 
stack  as  described  In  Function  Seven. 

This  function  shall  fetch  the  top  Interrupt  request  vector 

t 

(the  oldest)  and  use  It  to  Index  Into  the  Master  Request  Decode  Table  describ¬ 
ed  In  paragraph  3. 2. 2. 3.1.  If  this  table  Indicates  blt-or-word-makslng  mes¬ 
sage,  the  Master  Instruction  Supplement  Table  will  be  utilized.  As  Indicated 
in  paragraph  3. 2. 2. 3.1,  If  the  request  for  transmission  comes  from  a  Remote 
Terminal,  the  Master  Remote  Terminal  Request  Tables  shall  be  used  Instead. 

If  the  status  word  received  Indicates  a  status  word  error, 
the  error  processing  function  shall  be  Invoked  instead. 

The  processing  performed  by  this  function  is  Illustrated  in 

Figure  38 

3.2. 2. 3.3  Outputs  from  Asynchronous  Control  Function 

The  outputs  from  this  function  are  listed  In  Table  XXX 

3.2.3  Function  Thirteen  -  Monitor  Control  Functions 

The  monitor  control  functions  will  be  performed  by  the  Master 
Executive  residing  In  the  Monitor  Processor  only.  Its  functions  are: 

a.  To  receive  and  process  asynchronous  messages  from  the 
master  processor  updating  Its  bus  control  data  base. 

b.  To  monitor  the  master  processor  for  minor  cycle  synchroni¬ 
zation  operation. 

c.  To  assume  control  of  the  system  If  any  processor/BCIU 

falls. 

In  the  event  of  the  Master  Processor  or  Its  BCIU's  failure, 
the  monitor  control  function  shall  assume  control  of  the  system  automatically. 
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Figure  38  Asynchronous  Control  Function 


TABLE  XXX  OUTPUTS  FROM  ASYNCHRONOUS  CONTROL  FUNCTION 


If  a  remote  processor/BCIU  falls,  the  master  executive  In  the  master  proces 
sor  shall  confirm  the  failure  and  relinquish  control  to  the  monitor  proces¬ 
sor. 


t 


( 
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The  monitor  processor  shall  contain  also  a  local  .executive 
system  as  described  In  Section  3.2.1.  While  In  monitor  mode,  the  subset  of 
tasks  and  events  residing  In  the  monitor  processor  shall  be  updated  as  per 
request  from  the  other  processors.  No  data,  command  or  signal  transmission 
shall  be  generated  from  the  monitor  processor  while  In  the  monitor  mode. 


3.2. 3.1 


XXXI 


Inputs  to  Monitor  Control  Function 

Inputs  to  the  Monitor  Control  Function  are  listed  in  Table 


3.2.3. 2  Monitor  Control  Processing 

The  main  purpose  of  the  Monitor  Executive  function  is  to 
monitor  the  performance  of  the  master  processor  and  Its  BCIU  and  to  assume 
control  of  the  operating  system  upon  recognizing  the  master  failure. 


Upon  assuming  control,  the  operator  (pilot)  shall  be  informed 
of  the  failure  and  the  Monitor  Processor  shall  continue  In  control  of  the 
processing  system  until  reconf 1 guratl on  is  established. 


The  monitor  executive  monitors  the  master  processor  by  moni¬ 
toring  the  Issuance  of  minor  cycle  commands.  Upon  recognizing  the  lack  of 
minor  cycle  reception  for  N  minor  cycle  lengths,  the  monitor  shall  assume 
system  control. 


The  processing  performed  by  this  function  Is  Illustrated  In 

Figure  39 

3.2. 3. 3  Outputs  from  Monitor  Control  Function 

The  outputs  from  this  function  are  listed  In  Table  XXXI I 
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Figure  39  Monitor  Control  Processing 
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4.0 


QUALITY  ASSURANCE  PROVISIONS 


4.1  Introduction 

Tests  and  evaluations  shall  be  conducted  to  verify  that  the 
performance  and  design  of  the  OFP-Executlve  shall  meet  or  exceed  the  require¬ 
ments  specified  In  Section  3.0.  The  test  category,  verification  method,  and 
test  requirements  for  performance/design  requirements  are  specified  In  the 
Verification  Cross-Reference  Index  (VCRI),  Table  XXXIII.  The  requirements 
delineated  shall  be  the  basis  for  the  test  plan  and  test  procedure  which 
shall  be  written.  The  four  methods  given  In  Table  XXXIII  of  verifying  In¬ 
dividual  requirements  are  explained  as  follows: 

a.  Inspection  -  Formal  verification  of  a  performance  of  a 
design  requirement  by  examination  of  the  assembled  CPCI  at  the  time  and  place 
of  qualification  testing.  Inspection  is  not  often  specified  as  a  formal 
means  of  verification  for  a  requirement.  One  set  of  requirements  that  might 
be  verified  by  inspection  are  the  data  base  requirements,  which  can  be  veri¬ 
fied  by  comparing  the  data  base  documentation  with  a  system  tape  listing. 

b.  Analysis  -  Formal  verification  of  a  performance  or  design 
requirement  by  examination  of  the  constituent  elements  of  a  CPCI  component. 
For  example,  a  weapons  guidance  equation  or  a  coordinate  conversion  equation 
might  be  verified  by  analysis. 

c.  Demonstrati  on  -  Formal  verification  of  a  performance  or 
design  requirement  by  observation  of  a  demonstration  test.  For  example, 
visual  demonstration  might  be  used  to  verify  that  the  displays  generated  by 
the  CPCI  are  In  the  format  necessary  to  satisfy  human  performance  require¬ 
ments. 


d.  Review  of  Test  Data  -  Formal  verification  of  a  perfor¬ 
mance  or  design  requirement  by  examining  the  data  output  after  operation  of 
a  CPCI  component  when  selected  input  data  are  processed.  For  example,  a  re¬ 
view  of  hardcopy  printout  test  data  might  be  used  to  verify  that  the  content 
of  a  specific  told-ln  message  Is  correctly  processed.  This  method  Is  the 
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one  likely  to  be  used  for  the  majority  of  qualification  testing. 
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Narrative  data  pertaining  to  test  categories,  amplifying  the 
tabular  content  of  the  VCRI  are  specified  In  subparagraphs  below.  Test  re¬ 
quirements  referenced  In  the  VCRI  are  specified  In  4.2  and  subparagraphs 
thereto. 


4.1.1  Category  I  Test 

Category  I  testing  is  subdivided  Into  the  following  broad 


types : 

a.  Computer  Program  Test  and  Evaluation  -  Tests  conducted 
prior  to  and  In  parallel  with  preliminary  or  formal  qualification  tests. 
These  tests  are  oriented  primarily  to  support  the  design  and  development 
process. 


b.  Preliminary  Qualification  Tests  -  Formal  tests  oriented 
primarily  towards  verifying  portions  of  the  CPCI  prior  to  integrated  testing/ 
formal  qualification  tests  of  the  complete  CPCI  (sea  paragraph  4.1.3  below). 
These  tests  will  typically  be  conducted  by  the  contractor's  design  and  de¬ 
velopment  facilities. 

c.  Formal  Qualification  Tests  -  Formal  tests  oriented  pri¬ 
marily  towards  testing  of  the  integrated  CPCI,  normally  using  operationally 
configured  equipment  at  the  category  II  site  prior  to  the  beginning  of  cate¬ 
gory  II  testing.  This  testing  will  emphasize  those  aspects  of  the  CPCI  per¬ 
formance  which  were  not  verified  by  preliminary  tests.  The  testing  require¬ 
ments  which  cannot  be  verified  during  category  I  test  shall  be  specified  In 
paragraph  4.1.5. 


Qualification  of  this  CPCI  shall  be  accomplished  during 
qualification  testing  to  the  maximum  extent  possible,  as  a  result  of  prelim¬ 
inary  qualification  tests  (PQT)  and  formal  qualification  test  (FQP)  conducted 

by  the  contractor  and  witnessed/ verified  by  the  procuring  activity. 
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4.1.2  Computer  Programing  Test  and  Evaluation 

Programming  test  and  evaluation  which  apply  satisfy  one  or 
both  of  the  following  criteria: 

(?)  They  are  Intended  to  be  the  only  source  of  d^ta  to 
qualify  specific  requirements  In  Section  3. 

(2)  They  must  be  accomplished  as  part  of  an  Integrated  test 
program  Involving  other  systems/equipment/computer  programs. 

4.1.3  Preliminary  Qualification  Tests 

These  tests  will  directly  support  the  top-down  Implementa¬ 
tion  and  verification.  Method  of  verification  shall  be  as  specified  In 
Table  XXXIII.  The  following  three  levels  of  qualification  shall  be 

performed. 


a.  Unit  Design  Qualifications  shall  apply  to  each  module. 

At  this  level  the  characteristics  which  are  of  primary  interest  are  the 
internal  workings  of  the  module;  logical  flow  control,  numerical  results, 
convergence,  scaling,  and  range. 

b.  Module  Design  Qualifications  shall  apply  to  each  module 
after  it  is  interfaced  with  Its  environment.  These  tests  are  basically  In¬ 
terface  tests;  correct  internal  operations  are  assumed.  The  object  Is  to 
verify  that  two  or  more  modules  work  together.  To  comply  with  the  top-down 
approach  the  Interfacing  tests  shall  be  sequenced  from  the  top  to  the  bottom. 

c.  System  Design  Qualifications  shall  apply  to  the  completely 
assembled  CPCI.  This  level  requires  a  totally  Integrated  computer  program. 
Such  testing  discloses  errors  due  to  conflicts  Introduced  by  data  sharing 
convention  violations,  Improper  range  of  Input  values,  sequencing  require¬ 
ments  and  communications  and  control.  The  Internal  working  of  the  CPCI  Is 

of  primary  concern  with  the  Interfaces  of  the  CPCI  with  the  external  envlron- 
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ment  deferred  to  the  Formal  Qualification  Tests. 


4.1.4  Formal  Qualification  Tests  (Specified  In  the  Part  II 

Specifications) 


t 

4.1.5  Category  II  Tests  (Specified  in  the  Part  II  Specifications) 

4.2  Verification  Requirements 

This  paragraph  specifies  In  greater  detail  the  method  used 
to  verify  the  Individual  requirements  given  in  Table  XXXI II.  (This  table 
cross-references  the  sub-paragraphs  of  4.2  which  apply). 

4.2.1  Performance 

The  specified  function  shall  be  verified  with  respect  to 
one  of  the  following  performance  criteria. 

a.  Accuracy  which  may  be  affected  by  Input  precision,  input 
frequency.  Input  accuracy,  or  number  of  Iterations. 

b.  Execution  time 

c.  Storage  used 

d.  Response  time 

e.  Long  term  degradation 

f.  Stability 

4.2.2  Priori ty/TI ml nq 

The  specified  function  shall  be  verified  with  respect  to 
one  of  the  following  priority/ timing  criteria: 

a.  Interrupt  and  return 

b.  Frequency 

c.  Consistency  In  events 

d.  Order  of  processing 

e.  Scheduling/cancelling  consistency 

f.  Job  stacking 
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4.2.3  Interfaces 

The  specified  function  shall  be  verified  with  respect  to 
one  of  the  following  Interface  parameters: 

a.  Data  locks 

b.  Range 

c.  Consistency 

d.  Initialization 

e.  Data  organization 

f.  Human  command/response 

g.  External  procedures 

4.2.4  Logic  Paths 

The  specified  function  shall  be  verified  with  respect  to 
the  correctness  of  the  logic  paths  by  exercising  the  computer  program  In 
operation. 

4.2.5  Off-Nominal  Conditions 

The  specified  function  shall  be  verified  with  respect  to 
off-nominal  conditions  such  as: 

a.  Error  detection 

b.  Error  recovery 

c.  Limitations 
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